Proposal (was: Re: [JDEV] Unreliable?)

Thu May 3 08:52:29 CDT 2001

Well, i agree that this thing is bad in Jabber. Maybe something like;
The client sends something like <jabber:iq:embed/>, or
<supports>jabber:iq:embed</supports> within the jabber:iq:auth data when it
sends it.
Then, if the server supports this (if it doesn't, then it'll just ignore the
tag, XML-power :P), it would be able to send messages to the client embedded
inside a jabber:iq:embed info/query, and if it doesn't receive a reply within
30 seconds, will simply disconnect the client (will not 2nd message's iq,
before it received iq-result for the first). Also, the client will accept
normal messages.

In this way, if the client doesn't support jabber:iq:embed stuff, then it can
just connect as a regular basic client. If the client supports it, and the
server too, then the client will receive messages in a guaranteed way, but
will get disconnected if it doesn't reply within 30 seconds. Also, the server
won't send the client a second jabber:iq:embed info/query if it haven't
received reply to the first yet.

Also, the server will not accept any jabber:iq:embed info/queries from other
servers, nor other clients, and will reply itself with an error, to prevent
fake messages. And also, the client will reply with <iq type="error">, if it
receives a jabber:iq:embed info/query, whose from attribute isn't the server
it's connected to (it can check from the values in stream:stream tag)

I think this system will be pretty good, also we'll have a "supports" tag
implemented in the authorization protocol, which will allow advanced
server-client communications if both sides support.

An example connection may be (af
ter opening stream):

SEND: <iq type="get" id="0001">
SEND:  <query xmlns="jabber:iq:auth">
SEND:   <username>username</username>
SEND:   <password>password</password>
SEND:   <resource>resource</resource>
SEND:   <supports>jabber:iq:embed</supports>
SEND:  </query>
SEND: </iq>

RECV: <iq from="server.jabber.org" type="result" id="0001">
RECV:  <query xmlns="jabber:iq:auth">
RECV:   <supports>jabber:iq:embed</supports>
RECV:  </query>
RECV: </iq>

SEND: <presence/>

RECV: <iq from="server.jabber.org" type="set" id="AF0B">
RECV:  <query xmlns="jabber:iq:embed">
RECV:   <message from="user at users.server.com">
RECV:    <body>Jabber rocks!</body>
RECV:   </message>
RECV:  </query>
RECV: </iq>

SEND: <iq to="server.jabber.org" type="result" id="AF0B">
SEND:  <query xmlns="jabber:iq:embed"/>
SEND: </iq>

All please reply with your toughts about this stuff, i think this will be
best, and most Jabber-style way to do this.

Regards,
Kerem HADIMLI

travis at thinkvirtual.com wrote:
> 
> I think there should be some response from the client back to the server letting it know that it has received the message and can then delete.  If no response is returned, then it will retry, or wait until another presence from the client has been sent.  Something along those lines anyway.  It's impossible to get to trust something like this unless you know without a doubt that you are not going to miss any messages.
> 
> Travis
> 
> ---- Original Message ----
> From: "Thomas Parslow (PatRat)" <patrat at rat-software.com>
> Sent: 2001-05-02 10:44:38.0
> To: "travis at thinkvirtual.com" <jdev at jabber.org>
> Subject: Re: [JDEV] Unreliable?
> 
> > My main concern with jabber is that you can't always be guaranteed to receive a message.  Now most of my list is icq buddies, but I miss a lot of messages.  I tell people to email me if they want
> > to make sure I get it.
> >
> > Now I'm not sure if this is the server or the client (i'm using jim mostly)?  Or is it just that it's mostly from icq users?
> >

> > Could someone give me some insight into this?  Thanks.
> >
> > Travis Reeder
> > Chief Software Architect
> > ThinkVirtual
> 
> It's probably to do with the bug I pointed out a little while ago, for
> some people, if they go offline without first shutting down jabber then
> they appear to be online for up to 15 minutes, any messages sent to
> them in that time go to the big bit bucket in the sky...
> 
> Does anyone know if there are any plans to fix this?
> 
> Thomas Parslow (PatRat) ICQ #:26359483
> Rat Software
> http://www.rat-software.com/
> Please leave quoted text in place when replying
> 

-- 
If it happens once, it's a bug.
If it happens twice, it's a feature.
If it happens more than twice, it's a design philosophy.