On Mon, Oct 19, 2009 at 12:21 PM, Julien Genestoux <[email protected]> wrote: > > Huh... The http params parser that we use (in ruby) messes up with that... > :/ > > I'll see I'd there is any way around.
Yeah? Let's see how hard this is to get right from both the client (subscriber) and server (hub) perspectives. If it's easy for a client and hard for a Hub, that's fine. The subscriber is the important part. > On Oct 19, 2009, at 9:12 AM, Brett Slatkin <[email protected]> wrote: > >> >> On Mon, Oct 19, 2009 at 11:55 AM, Pádraic Brady <[email protected]> >> wrote: >>> >>> Hi all, >>> >>> Just wondering if we could clarify the construction of the hub.verify >>> parameter in the spec. There are two terms used in Section 6.1 "keyword" >>> and >>> "parameter". My own reading has me interpreting the sentence "This >>> parameter >>> may be repeated to indicate multiple supported modes." as meaning >>> something >>> like: >>> >>> hub.verify=sync&hub.verify=async >>> >>> Whereas the final sentence refers to "Where repeated keywords are used, >>> their order indicates the subscriber's order of preference", which seems >>> to >>> suggest: >>> >>> hub.verify=sync,async >>> >>> I went with the first initially since it seemed to be saying the >>> parameter >>> could be repeated, but I gather Superfeedr (haven't checked the reference >>> hub tests yet) rely on the keywords existing within a single parameter >>> (comma delimited). >>> >>> I'm confused myself as to which is correct. Note that the first does get >>> treated differently by http clients. Some will compact the first >>> automatically into the second example (so they end up the same anyway), >>> others will simply drop one of the parameters instead of compacting them. >> >> Initially it was #2. Then we changed it to #1 in the 0.2 spec. >> Python's CGI module will give you back a set of key/list pairs, with >> the values listed in the order they appeared in the string. >> Query-string encoding does enough variable munging that we shouldn't >> have to add yet another level of parsing on top of that, which is why >> we're going with #1. How hard is it to make this work right in PHP for >> clients? >
