>> 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 second that. It is not a payload issue, neither a client discovery one, but a protocol flaw (using a generic message of type chat when something specific should be used). We are solving this a different way in onesocialweb and this could become an extension to PEP and/or PubSub. Here is the flow: - User subscribe to a node (e.g. urn:xmpp:microblog:0) with a bare JID - Event messages are sent to the bare JID and have a new type (e.g. pubsub) - The server does not forward the messages to connected resources, instead, it puts the message in the 'PEP Inbox' (a pep node to which only the owner has access) - Clients interested in that content, subscribe to the PEP Inbox using presence based subscription => Only the clients that understands the payload and can do something meaningfull get it. It could even be evolved with more filtering options (e.g only PEP events related to the node xyz, etc...). => This also solves the off-line issues related to this kind of messages (if you want to query past messages in your inbox, it is a simple <items/> request. What do you think ? Worth moving forward as an extension to PEP or PubSub (e.g. PubSub inbox protocol). Is there other ideas/proposal out there on the concept of a PubSub inbox ? Laurent Eschenauer
