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?
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
