It's annoying because I don't think "arrays" are standardized very well in HTTP. I know PHP also uses the [] convention, and apparently so does Rack... which is surprising. Almost every other environment I know (pretty much all python) don't need [] to parse into an array (at the expense usually of not knowing if it's single value or multi value).
-jeff On Mon, Jan 18, 2010 at 3:56 PM, [email protected] <[email protected]>wrote: > it's a rack thing - here are the rack specs > > Rack::Utils.parse_nested_query("foo=bar&foo=quux"). > should.equal "foo" => "quux" > > Rack::Utils.parse_nested_query("foo[]=1&foo[]=2"). > should.equal "foo" => ["1", "2"] > > so I'd need something like... > > req.body = req.body.gsub('hub.verify=', 'hub.verify[]=') # Part 3 of > multivalue hack > > or just pull them manually from the request.env > ["rack.request.form_vars"] > > I'll implement the latter or maybe alter rack slightly (locally) -- I > think there are actually a few places that this occurs in the python > spec. > > Thanks again for the quick review, > > Mike > > > On Jan 18, 12:39 pm, Michael Barinek <[email protected]> wrote: > > Correct, I believe that's the issue. I'll take a look as well when I get > > a chance. > > > > (for the other...I just needed to remove some load on the server/queue) > > > > Jeff Lindsay wrote: > > > Ohh, I see. Rack/Sinatra only supports single value params? Perhaps MY > > > multivalue hack (since http/net doesn't support sending multivalue > > > params) isn't working... > > > > > On Mon, Jan 18, 2010 at 11:25 AM, Michael Barinek <[email protected] > > > <mailto:[email protected]>> wrote: > > > > > Agreed, the first passes. > > > > > Although, the subscribe for 'Hub subscriber interface MUST ignore > > > verify keywords it does not understand' includes > > > ['sync','foobar','async']. I only receive one param in the rack > > > request and locally I'm getting 'foobar' -- hence the resultant > > > "Invalid values for hub.verify: foobar" or 400 response code. > > > > > Mike > > > > > Jeff Lindsay wrote: > > > > > The only thing specific to App Engine is a check to see if it > is > > > a local dev environment for the reference hub, in which case it > > > triggers the task queue so it finishes its cycle needed for it > > > to pass the test. > > > I'm not sure how you see that or the need for a multivalue hack > > > based on the failed tests you shared. > > > > > The first is the result of your hub not fetching published > > > content after being pinged, and the second is just saying you > > > shouldn't allow a catch-all for verify values. I'm not terribly > > > sure why that's in the spec as a MUST, but it is. > > > > > -jeff > > > > > On Mon, Jan 18, 2010 at 10:45 AM, [email protected] > > > <mailto:[email protected]> <mailto:[email protected] > > > <mailto:[email protected]>> <[email protected] > > > <mailto:[email protected]> <mailto:[email protected] > > > <mailto:[email protected]>>> wrote: > > > > > Cool, looks like most of the tests pass (failed below). For > > > the first > > > I would also need to include a multivalue hack...and the > > > second seems > > > to require Google app engine. > > > > > I'll take a look/maybe implement the 'Not Yet Implemented' > tests. > > > > > I've also considered moving the queue to sqs and model > > > objects to s3 > > > -- or similar (basically Gnip's original architecture). If > > > anyone is > > > interested in lending a hand let me know. > > > > > 1) > > > 'Hub publisher interface sends an HTTP GET request to the > > > topic URL to > > > fetch content' FAILED > > > expected: "GET", > > > got: nil (using ==) > > > ./hub_spec.rb:59: > > > > > 2) > > > 'Hub subscriber interface MUST ignore verify keywords it > does not > > > understand' FAILED > > > expected #<Net::HTTPBadRequest 400 Bad Request > readbody=true> > > > to be a > > > kind of Net::HTTPSuccess > > > ./hub_spec.rb:91: > > > > > On Jan 18, 2:48 am, Jeff Lindsay <[email protected] > > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > > > Also! Please use (and update if necessary) the hub > > > testsuite we > > > > > made: > http://code.google.com/p/pubsubhubbub/source/browse/trunk/testsuite/R... > > > > > > Luckily for you, it happens to be written in Ruby! > > > > > > -jeff > > > > > > On Sun, Jan 17, 2010 at 5:47 PM, Brett Slatkin > > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > > > > On Sun, Jan 17, 2010 at 4:48 PM, [email protected] > > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> > > > > > > > wrote: > > > > > > Is there any interest out there for a full Ruby > > > implementation? It's > > > > > > pretty much a straight port using Sinatra and Redis > > > including > > > a basic > > > > > > task queue. I'm currently testing the hub on AWS and > > > hoping > > > to open > > > > > > source the code on GitHub. (I've also ported most of > the > > > python tests) > > > > > > > That'd be awesome! > > > > > > -- > > > > Jeff Lindsayhttp://webhooks.org--Make the web more > > > programmablehttp://shdh.org--A party for hackers and > > > thinkershttp://tigdb.com--Discover indie > > > gameshttp://progrium.com-- > > > More interesting things > > > > > -- > > > Jeff Lindsay > > > http://webhooks.org-- Make the web more programmable > > > http://shdh.org-- A party for hackers and thinkers > > > http://tigdb.com-- Discover indie games > > > http://progrium.com-- More interesting things > > > > > -- > > > Jeff Lindsay > > >http://webhooks.org-- Make the web more programmable > > >http://shdh.org-- A party for hackers and thinkers > > >http://tigdb.com-- Discover indie games > > >http://progrium.com-- More interesting things > -- Jeff Lindsay http://webhooks.org -- Make the web more programmable http://shdh.org -- A party for hackers and thinkers http://tigdb.com -- Discover indie games http://progrium.com -- More interesting things
