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?
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.
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
