Vendanthe last time I tried to optimize php fastcgi, I ended up writing the fastcgi serverloop in php itself, cause php, even with opcode caching and all, still read the php code off the disk for every request
Vendansomething in my is still like "oh, I could do so much better" and the other part is like "What's the point, it's 100000x more then I need at this point"
LoqiThe WordPress Outreach Club is a group of active IndieWebCamp participants who reach out to individuals already running WordPress to add IndieWeb functionality to their existing sites https://indiewebcamp.com/WordPress_Outreach_Committee
Vendanone of my thoughts, for when broadband starts picking up, is to package up a small image for something like CHIP or a raspberry pi, that'll be your indieweb
Vendanbut yeah, I can respect the whole convert users that are on wordpress already, just nowhere near willing to install it on my server or deal with PHP outside of work
GWGI'm trying to design better display code. So, basically, I've built a system to store and retrieve information about a post...I want to display it with the appropriate markup.
Vendanso if I want a different style of post rendering, for stuff like reply-context, I can just use the same structs and pass a different template object
atomiculesHello. Just dropping in to say that since starting with Indieweb at the start if this year, I've now implemented POSSEing links, photos and notes
voxpelliatomcules: you can always export all of the mentions from my endpoint, so it could be a way for you to get started, and then you can move to your own when you have one
voxpellibeen thinking to maybe add a passthrough options for the webmention pings so one could have my endpoint forward a ping to another endpoint – to ease the transition
LanceyWorkatm i've just checked if the atref is a valid domain name, did a get on the site, searched for rel-me links to twitter, and pulled the handle off that
tantekLanceyWork - there's a bunch of work and previous sessions on the wiki that folks have discussed re: auto-completing names/URL of people including @-names
tantekmarcthiele++ for co-organizing IndieWebCamp Germany and helping with venue and all the other things that helped make IndieWebCamp Germany awesome!
tantektommorris: I don't really see the usefulness of such a page /standards_efforts as it is now - and frankly, I've seen far too many such random lists of projects/standards on wikipedia that are nearly useless (but I have no desire to get into a wiki-edit fight with anyone there about)
tantektommorris: the #microformats wiki is a more appropriate place to just do arbitrary documentation of prior standards work/attempts/proposals like that.
tommorristantek: the existing list was more focussed on the standards that indiewebcamp was using. I kind of wanted a list of standards we'd looked at, so we could document them. if it's out of scope, happy to delete/revert or move
tantekalso - that kind of framing with "implied moral of this list" will likely just invite more defensive talk/conversations about standards no one is actually building on for their own sites - and thus be a distraction / noise amongst the rest of our more focused / productive discussion in IWC
tantekso I guess two things: 1) I don't think such a general (no specific category/focus) list of past efforts is useful on IWC. 2) there may be some instances where it is worth documenting *specific* such efforts on their own pages, e.g. by listing the modern replacement that supersedes the prior effort
tanteke.g. one or more of 1. indieweb community folks support it live on their site (thus non-empty IndieWeb Examples section). 2. indieweb community folks *tried* supporting it, and gave up, for *specific* reasons (must be documented). 3. indieweb community folks looked it, but didn't bother to even try supporting it for *specific* reasons.
tantek4. indieweb community created something that *supersedes* the prior effort, and thus it helps to create a page for the prior effort just to at least redirect people to the new/modern thing that supersedes it.
tantek5. more than one person in IRC has asked about the past effort, and there was sufficient response discussing why the past effort is not in use by the indieweb community to document a specific Criticisms section for that specific past effort
tantekbut the larger point is, simply yet-another-unfocused-list of previous efforts is not helpful to anyone and may actually incite more noise than signal
LanceyWorkif it's a tweet permalink, or something that's been tweeted (ie posse'd from another indiewebsite), then specify the tweet as in_reply_to_status_id
tantekyeah I wrote most of the /Twitter page incrementally while implementing the functionality on my site (and in my software /Falcon ) - though at some point I started extrapolating so now the /Twitter page goes beyond what I've implemented so far (but serves as a checklist for my future coding)
tantekI wrote tw_url_to_status_id semi-defensively so you could throw any URL at it and have it return 0 or a valid status ID, with nearly no chance for false positives
tantekmarcthiele++ for co-organizing IndieWebCamp Germany and helping with venue and all the other things that helped make IndieWebCamp Germany awesome!
tantekaaronpk - at some point you way want to consider forking the PubSubHubbub spec, since specs work best when their editor(s) are actively selfdogfooding what's in the spec.
tantekaaronpk: it is good to avoid forking a spec until you feel you must (i.e. disagreement with nonselfdogfooding editors), or when your contributions approach ~50% of the spec.
tantekone of the good reason to do so, if you're willing to rewrite all the content, is to license it more liberally - since according to Harry the existing editors / Google didn't want to contribute the spec to W3C or sign an IP agreement to allow its re-use.
aaronpkVendan: your website supports PuSH 0.4 in that subscribers can read the spec and subscribe to your site. but no you have not made a 0.4-compliant hub
aaronpkit bugs me because at the top of the 0.4 spec it says "To dramatically simplify this spec in several places where we had to choose between supporting A or B, we took it upon ourselves to say "only A", rather than making it an implementation decision."
tantekaaronpk - that sounds like that "bunch of places" are all issues to be filed, where you say, per your spec methodology, I say choose A (or choose B - whichever *you* aaronpk think is the better answer)
tantekvoxpelli: the spec should clearly cite the copyright and patent policies, preferably by linking to a generic license rather than making up their own
julien51wowo, tantek, what I’m reading here baffles me! lots of lies! It also saddens me that you’d say things like “ since according to Harry the existing editors / Google didn't want to contribute the spec to W3C or sign an IP agreement to allow its re-use.”. Don’t you know how to reach me?
tantekjulien51: it's possible that Harry asked them first (since they're at the top), got a "No" answer, and then gave up because all editors would have to agree to contribute / openly license
tantekcontinuing: however, if 0.4 is a rewrite of 0.3 + new features you wrote, then it's more appropriate to list them in an informative Acknowledgments section as authors of the previous version
julien51as for 0.4, there’s a lot of new things I wrote (you can see the diffs easily on the GH repo), but in any case *they* fostered the field and the spec, so no, I won’t take them out.
voxpelliregarding the PuSH-issue – seems to me like the current disagreement is mostly around where to add a standardized way rather than if there should be a standardized way? rather than just making a draft first and deciding where it belongs later on?
tantekLet's act on the assumption that the PuSH editors are reasonably amenable to receiving such clarifying pull requests and will incorporate accordingly
aaronpkokay so here's an example, currently superfeedr and google support publish requests like this: "hub.mode=publish&hub.url=X". That bugs me because "url" is ambiguous, and is in fact the topic URL which was named "hub.topic" in other parts of the spec. I would like to change it to "hub.topic" for the publish request
aaronpksince that is not part of PuSH 0.4 I can do that on my hub and still have it be 0.4-compliant. Assuming making any recommendation of payload won't be accepted into the spec by julien, is my next best option to file a feature request on superfeedr to accept that parameter name?
voxpelliprobably, but is it really worth breaking compatibility with the 0.3 spec (which still is the most established PuSH-spec) just for a little more consistent naming?
julien51the distinction is that the publisher tells the hub that a resource (hub.url) was changed… when people could have susbcribed to a different one
julien51the most common use case would be: the publisher pings with a blog url when the subscriber has subscribed to a feed url related to that blog url
julien51one of the key design principle of PuSH was to push complexity down to the hub, and the hub alone should ‘link’ hub.topic(s) with various hub.url(s)
julien51one of the most “frequent” ones was that feedburner URLs are case sensitives… and it pinged the hub with different url (just a case difference) than the ones used by susbcribers… and The Google hub was not great at dealing with this
aaronpk!tell cweiske would you consider updating phubb to accept "hub.topic" for the publish request? if so, then all 3 public hubs support it and I'll change the how-to-push page to recommend it
Loqicweiske: aaronpk left you a message 1 hour ago: would you consider updating phubb to accept "hub.topic" for the publish request? if so, then all 3 public hubs support it and I'll change the how-to-push page to recommend it http://indiewebcamp.com/irc/2015-05-19/line/1432056978895
aaronpkokay make an argument for hub.url in the publish again. my main concern is that it is inconsistent with itself because subscribers use hub.topic
Vendannamespacing is when you separate groups of items based on common usage or creation, commonly used in programming and protocols, but can be over applied
aaronpkpresumably if you get a request that sends "mode=subscribe" instead of "hub.mode=subscribe" you should not use the namespaced params when verifying
Vendanit's a named set of "things". in PuSH, we're refering to a set of parameters, in programming languages, it's a named set of classes, in xml, it's a named set of tags
kylewmtantek: my understanding of the timeline is like 1) they chose "topic" to be generic, imply that you could subscribe to anything, 2) much later superfeedr added support for search queries and chose to implement them URLs
tantekURL is not universal enough, let's invent a new term "topic" to be *more* universal. Sigh. some combination of xkcd 927 and /architecture-astronomy
kylewmso amusing semi-related aside: java.util.File has as method toURL() which is deprecated in favor of toURI(). so now you always have to call file.toURI().toURL()