[Standards] adding body as RECOMMENDED field for PEP-protocols?
stpeter at jabber.org
Tue Jun 12 15:25:39 UTC 2007
Adam Nemeth wrote:
> Hi all,
> It's been in my head for 3 weeks, so I thought I should ask this
> before it runs out:
> I think that eventing protocols, like User Tune, User Mood, User
> Activity, and User Geolocation are pretty much the same: the user
> emits some signal which interested parties could catch
> BUT: only if their client is capable of catching such events.
> What if I invent the 'User Playing' protocol, or 'User Watching', or
> 'User Browsing' protocol, should I make a plugin/patch for every major
> client, by copying for example, User Tune handler, and rewrite two
> lines to match my namespace?? For the sake of what?
> Couldn't we just put a <body> or anything <human-readeable> field as a
> recommendation to all these protocols just in the case the client does
> not implement the given protocol, but otherwise wants to show their
> users what happens now?
> Of course, such body element's rendering is entirely based on the
> SENDER's side, in case the receiver does not support such -when it
> does, it can render it in its own will (next step would be defining
> XSLTs, but that's a later story)
> Disabling such events could be done either by namespace and/or
> capability (I believe it would be worse if we always allow only the
> smallest possible sets of features), in some cases it's just a
> rendering issue (display-or-not).
> I was told by stpeter that body element is a standard feature of PubSub.
There is a mention of this in XEP-0060 but it is not very prominent.
I'll look into making it more prominent in the next version.
But in order to send out a plaintext message <body/> doesn't some entity
(either the publisher or the pubsub service) need to know how to
translate the XML semantics into human-readable text?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards