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="[EMAIL PROTECTED]">
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
[EMAIL PROTECTED] 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)" <[EMAIL PROTECTED]>
> Sent: 2001-05-02 10:44:38.0
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> 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.
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
