Other than orthogonality, I don't understand the use case for hydrated deletions. They're useful to delete existing data. What would you display, and why?
Note that every byte that we send costs something in CPU, bandwidth and increased latency. On Fri, May 7, 2010 at 2:38 AM, lqd <remy.ra...@gmail.com> wrote: > #1 OAuth. > This took a long time to debug but I think I found the problem. It > looks like you guys expect the OAuth Authorization header params to be > separated by a comma (which is OK), AND at least one space (which is > not OK). Am I right ? (The spaces after the comma are optional if I > remember the OAuth spec correctly.) > > #3 The use cases for hydrated delete events would be exactly the same > on your part as the ones for hydrating social events :) (which I > believe is to make the stream more useful by itself and not *having* > to use the REST API to understand the stream events). I keep user > objects ATM, or ask the REST API for statuses or user ids I didn't > encounter before, there's no question that it's doable, I was just > wondering whether the same thinking would be applied consistently to > all events, the delete ones right now and any new ones created in the > future ? > > Thanks Mark and John > Rémy > @ldq > > On May 6, 6:46 pm, Mark McBride <mmcbr...@twitter.com> wrote: >> Did you adjust the timestamp in that tool? The hosebird >> implementation tolerates at most a 5 minute clock skew... in other >> words if it receives a timestamp that is 5 minutes older (or newer) >> than the current time, it rejects the request. >> >> ---Mark >> >> http://twitter.com/mccv >> >> >> >> On Thu, May 6, 2010 at 6:39 AM, lqd <remy.ra...@gmail.com> wrote: >> > Hey guys, a couple questions/remarks on the new user streams features: >> >> > 1) OAuth >> > I have no problem using the stream with BasicAuth, nor using the REST >> > API with OAuth. However I'm always getting 401s with OAuth on the >> > stream, even though Zac's fork or earlybird works flawlessly. >> > Just to try and locate the problem I tried signing the request with >> > the official noob tool >> > athttp://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signin... >> > and sending the header with curl (with fiddling with spaces, tabs & >> > newline just in case, and even the realm value - just because >> > earlybird's impl doesn't send it), and I still can't login. While my >> > own code signing matches the parameters this tool outputs (and works >> > on api.twitter.com) it doesn't match what the ruby gem generates, even >> > when using the same timestamp and nonce, so I was suspecting some >> > difference in the base string. (I don't know Ruby, or how to get the >> > Base String there, but there's apparently a signature_base_string >> > method, and it did seem to have all the oauth params in the query >> > string) >> >> > 2) +1 on the user burping at the beginning :) >> >> > 3) Are the deletion notices going to be hydrated too ? ATM it's a >> > little raw. While it's understandable for the status not to be there >> > since it's just been deleted, maybe the full JSON user could be there >> > instead of just its id ? >> >> > Thanks >> > Rémy >> > @lqd >> >> > On May 6, 12:41 am, Mark McBride <mmcbr...@twitter.com> wrote: >> >> Ok. The query string OAuth variant should be working now. We only >> >> support HMAC-SHA1 (just like twitter.com does) for signature methods, >> >> and don't have plans to support other schemes. >> >> >> ---Mark >> >> >>http://twitter.com/mccv >> >> >> On Wed, May 5, 2010 at 3:21 PM, John Kalucki <j...@twitter.com> wrote: >> >> > We should probably just burp the whole user object out at connection >> >> > start. >> >> >> > On Wed, May 5, 2010 at 3:12 PM, Zac Bowling <zbowl...@gmail.com> wrote: >> >> >> Hydrated message support in earlybird! >> >> >> >>http://github.com/zbowling/earlybird/ >> >> >> >> OAuth in query string doesn't work and only HMAC-SHA1 signature >> >> >> (unless you >> >> >> only allow plaintext over SSL) but its fine. >> >> >> >> One feature request would be an inital event with the users >> >> >> credentials just >> >> >> like how the user's social graph comes down initially. Right now I >> >> >> don't >> >> >> know the user's screen_name unless I also hit api.twitter.com or he >> >> >> tells me >> >> >> on the command line. With that I could drop the dependency on the >> >> >> twitter >> >> >> gem. >> >> >> >> Zac Bowling >> >> >> @zbowling >> >> >> >> On Wed, May 5, 2010 at 10:54 AM, Mark McBride <mmcbr...@twitter.com> >> >> >> wrote: >> >> >> >>> It should support both. Can you send me a direct email with a URL >> >> >>> that you tried? >> >> >> >>> ---Mark >> >> >> >>>http://twitter.com/mccv >> >> >> >>> On Wed, May 5, 2010 at 10:38 AM, Zac Bowling <zbowl...@gmail.com> >> >> >>> wrote: >> >> >>> > My fork of earlybird works: >> >> >> >>> >http://github.com/zbowling/earlybird/ >> >> >> >>> > Fixing it to support hydrated objects. >> >> >> >>> > One thing is that it doesn't appear to support query string passed >> >> >>> > OAuth >> >> >>> > params but if I pass it as authentication headers it works. >> >> >> >>> > Zac Bowling >> >> >> >>> > On Wed, May 5, 2010 at 10:31 AM, Mark McBride <mmcbr...@twitter.com> >> >> >>> > wrote: >> >> >> >>> >> OAuth support on betastream is live now. This is different OAuth >> >> >>> >> implementation than we use on twitter.com, so if you find any rough >> >> >>> >> edges please let us know quick like. >> >> >> >>> >> The changes to make direct messages more distinguishable from >> >> >>> >> tweets >> >> >>> >> has also been pushed. This will probably require some changes in >> >> >>> >> parsing logic when dealing with DMs. >> >> >> >>> >> ---Mark >> >> >> >>> >>http://twitter.com/mccv >
