[JDEV] Roster and presence

[Scott Robinson]

Storing individual client preferences in the server seems a bit heavy.
(although it does have it's pluses) I might suggest hammering out certain
presence options, which were planned anyway but never implemented, in
allowing the client a little more control over how the server handles its
roster and presence.

Do we want to force a subscription before a "probe" will be responded to?
Do we want to reply with "subscribed" packets, or should the be able to be
told to auto-subscribe?

All this and more on the next,

Scott Robinson.

* Steven Wagner translated into ASCII [Mon, Jan 10, 2000 at 01:01:15AM -0800][<38799FDB.7130F136 at shwag.org>]
> 
>     How about just adding on the server stored roster a XML variable tag that
> allows for any additional data per user on the roster to be stored.  This way
> the client can store any extra data about the user that it chooses.  The server
> can have a configuration variable that specifies the maximum amount of data that
> is allowed per user on roster.  It could be limited to say 500 characters.  Or
> you can simply limit the size allocated per every account of the server which
> would limit the size of the users roster all together.  Let me know if I am
> making any sense.
> 
> Steven W.
> 
> 
> Stanislav Angelov wrote:
> 
> > I think you didn't understand me.
> >
> > The problem is not to substitute multiple dialog boxes with just one dialog.
> > The annoying part is to pay attention to dozens of subscription requests
> > during the chat session. For well-known users I would like to set my
> > permission/rejection setting just once and the client application silently
> > to give the right response without bothering me.
> > Also, responding to subscription requests is not one-time process during
> > startup. It is up to the other peers to decide when to bother you with
> > subscription requests ;-). You can well have to answer one request every two
> > minutes or ten at a time during your chat session.
> >
> > So, I need an information field for each user in my roster that instructs
> > the client how to handle subscription requests by the particular user for
> > me. I can maintain such information locally on the machine, but since my
> > roster info is on the server, its is a good idea my preferences for the
> > buddies in the roster also to be on the server and come together with the
> > roster info.
> >
> > Best Regards,
> > Stanislav
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
> 

-- 
jabber:quad at jabber.org         - Universal ID (www.jabber.org)
http://dsn.itgo.com/           - Personal webpage
robhome.dhis.org               - Home firewall

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GAT dpu s+: a--- C++ UL++++ P+ L+++ E- W+ N+ o+ K++ w++
O M V PS+ PE Y+ PGP++ t++ 5++ X+ R tv b++++ DI++++ D++
G+ e+ h! r-- y-
------END GEEK CODE BLOCK------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20000110/b6bb6e35/attachment-0002.pgp>