On 30/04/2010, at 6:25 AM, Brion Vibber wrote:

>> On Thu, Apr 29, 2010 at 12:04, Dave Cridland <dave at cridland.net> wrote:
>>> Any obvious first steps? Lose the Atom? Make XHTML-IM optional? How might we
>>> avoid forcing options on users? Disco for capabilities with positive
>>> stickiness?
>> 
>> IIRC the issue is that they want the display capabilities that
>> XHTML-IM affords but not all clients handle it the same so they repeat
>> the data.  The Atom portion is now standard for OMB and Activity
>> Streams.
>> 
>> IMO clients and servers should now "do the right thing" with Atom
>> payloads and we can get rid of most of it.
> 
> That Atom payload dates from 2008 and was introduced for compatibility with 
> XMPP-enabled Twitter clients... remember when Twitter had an XMPP interface? 
> :)

Yes - shame it's gone...

> 
> StatusNet's Atom feeds have gotten a lot more verbose lately as we've been 
> adding metadata (PuSH, ActivityStreams etc), so those packets have indeed 
> been getting fatter...

Without replaying this thread, we've noticed, our client app is StatusNet 
'aware', we render a single GUI based for all posts so have been grappling with 
the issues in this thread.

fyi - 
http://www.davidbanes.com/2010/04/12/a-couple-of-detail-pics-of-cleartext-esm-desktop/

We've been working with ProcessOne's Twitter gateway, and numerous XMPP bots, 
eg FriendFeed, Jaiku, Yammer etc which has uncovered the mess that is caused by 
lack of a standard for translating microblogging posts (and comments) into a 
common XMPP stanza. 

> 
> I'm not 100% sure anyone actually uses the Atom data in the XMPP feeds 
> anymore; before figuring out whether discovery would be worth implementing 
> I'd like to get some feedback from anybody who is using (or looked into but 
> chose not to use) that Atom block to find out if they'd be affected if we 
> just dropped it entirely!

I think we are, and would be happy to see Atom as the standard delivery wrapper.


> 
> -- brion vibber (brion @ status.net)

Reply via email to