[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jabber-jdev
Subject:    RE: [JDEV] 0.7 Proposed Protocol Changes
From:       Jeremie <jeremie () jabber ! org>
Date:       1999-09-28 14:36:58
[Download RAW message or body]

> You mention the server auto forwarding via a transport to other devices. Can
> presence information be feed (from transports) to a central points for
> determination of what to do. Is the server designed to handle determination
> of best method of contactability. I leave my PC on all day (hence maybe
> logged in) but I'm not always at mydesk but I have my mobile with me.(also
> SMS enabled)  The client may notify of an instant contactability timeout
> period .

Yes, the server will do determination of which "path" to the user is the
best path.  For the first run here with 0.7 it will use a simple priority
integer, your current location's resource would have the highest integer.
We might need something more complex in the future, but this simple
priority will work to experiment with.

> Also given the above. I was taking nickname to be like  someone's "role" ie
> work or home and hence different levels of contactability for each rather
> than a contactability device / resource. There may be different rosters for
> each of these roles.

Yes, of course, any "resource" could and would often be their
nickname/role for their sessions and each resource would be a different
level of contactability.  One of the things that needs to be addressed
within the presence system is how to express the "type" of resource it is
so that other clients can provide some sort of visual representation that
a particular resource is a device, pager, live session, etc.

Also, on the different rosters for the different roles, I hope that the
roster info/query exchange would support each resource having different
default rosters but I haven't decided on the syntax just yet.

> I see this as important particularly in line with IMPP model and ubiquitous
> IM. All of this requires serverside processing.

Absolutely, I'd like to stay as close to the IMPP model as possible, so
that it is easier to adopt the protocol when it is available.

Let me know if I didn't answer any of your questions or misunderstood
them,

Jer



[prev in list] [next in list] [prev in thread] [next in thread]