[jdev] sending custom messages from one client to another

Sun May 2 09:13:21 CDT 2004

On Sat, 1 May 2004 09:28, Justin Karneges wrote:
> This reminds me of an issue I've had regarding <message> stanzas.  Since
> you can have multiple top-level children with different namespaces, this
> leads to a lot of different possibilities for processing a message,
> particularly uses that are non-IM.  For instance, what if you get an RPC
> call like in your example that contains a <body>.  Does the client perform
> the function, display the body, or both?  I don't think this is defined
> anywhere.
>
> I think we should have some sort of guideline that developers should
> follow. Here is what I came up with:
>
> 1) If there are any 'attribute' elements like x:delay, <amp>, etc, then
> these can be accounted for as they apply to any kind of message.

Yeah, definitely in this case you need to do both.

> 2) If there are elements recognized by the client as non-IM (such as IBB
> data or a chat state change), then the client should process the stanza in
> this way.  If there are multiple such elements, then only one kind of
> processing should be performed.  Which one to choose would be
> implementation specific, but probably picking the first one recognized
> would be fine.  End.

I would say that multiple need to be accounted for in this case, actually, 
rather than ignoring further ones.

> 3) If there are elements recognized by the client as text, such as <body>
> or <html>, then the message should be considered an IM.

Other than needing to move this step to last place, this is spot on.

> 4) However, if there are elements recognized by the client as
> psuedo-attachments, such as contact items, groupchat invites, x:oob urls,
> then these can be processed as either an IM (with empty body if <body> is
> not present), or in a special way.

And multiples definitely need to be handled here because you might send 
multiple attachments.

Of course there are much more sophisticated things which could happen.  You 
could receive a message which contains nothing but an encrypted message, 
which when unwrapped, contains a signature, a body, and a bunch of attached 
roster items.  The encrypted message when encountered would be unwrapped, and 
then pushed back to the top of the chain.  The signature when encountered 
would be checked, and the message would be pushed down to the next point in 
the chain.

I think what we really need is a defined chain of processing by the client for 
message stanzas, so that all clients can follow a single guideline, and so 
that maybe even the JEPs could specify which point in the pipeline each 
different JEP applies to, if the processing is relevant to the particular 
JEP.

TX

-- 
'Every sufficiently advanced technology is indistinguishable from magic' - 
Arthur C Clarke
'Every sufficiently advanced magic is indistinguishable from technology' - Tom 
Graves

             Email: Trejkaz Xaoza <trejkaz at xaoza.net>
          Web site: http://xaoza.net/trejkaz/
         Jabber ID: trejkaz at jabber.xaoza.net
   GPG Fingerprint: 26CF 8621 223F 3916 8872  65C5 9A27 F3C0 130F C71A