On Thu, Apr 29, 2010 at 12:29, Dave Cridland <[email protected]> wrote: > On Thu Apr 29 17:20:36 2010, bear wrote: >> >> I'm not talking about server side issues - the server should pass the >> Atom portion on to the client just like it does everything else. >> >> The *client* tho should be able to handle Atom and create a >> displayable item from the Atom - it requires similar parsing issues as >> XHTML-IM IMO >> >> > Well... leaving aside for a moment whether clients should understand Atom > for other reasons, it strikes me that given that much of the information in > the Atom portion is static and not actually related to this message, per-se, > can't it be requested on demand? And doesn't this entire thing start to > suggest that really, OMB/XMPP should be using something more complex for > "willing participants", as compared to just bombarding clients with Atom?
That was one of my thoughts as I was reading your first post/question -- why not provide the source id (or url) and let clients who require/want the Atom items to request it as needed if they don't want to send to the server the DISCO item to enable full Atom support > > I mean - yes, absolutely, support naïve clients which haven't the faintest > idea they're talking to an OMB service, but I don't see those as likely to > understand all the Atom blurb anyway. Oh the other hand, if a client *knows* > about "OMB/XMPP", it can do clever stuff, and keep itself updated with all > the profile data it needs without it being sent continuously with every > message, and therefore doesn't need the full Atom blurb... > > >> But what Kevin suggests in his reply I suspect is the real answer - >> the Identica bot should grok client capabilities and not send all the >> stuff in the first place. >> >> > Right - but what about when clients are offline? Is it a case of > last-known-state wins? The trouble being we're assuming the last case will > be the next - if you're alternating between Atom/XHTML-IM aware client and > a non-aware, maybe mobile, client, you'll be gettign precisely the wrong > behaviour. I suspect that this is the root of why it's all included, well, that and the fact that Twitter sends *everything* > > Dave. > -- > Dave Cridland - mailto:[email protected] - xmpp:[email protected] > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade > -- Bear [email protected] (email) [email protected] (xmpp, email) [email protected] (xmpp, email) http://code-bear.com/bearlog (weblog) PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29
