On Wed, Mar 4, 2009 at 3:05 AM, Peter Saint-Andre <[email protected]> wrote: > > What is the definition of "activation"? Does that mean I receive > presence only from the groups I have activated, or that outbound > presence notifications are also filtered? >
Uff, each time I restart the discussion (also internally) new cases come up! Let's resume the situation, also for me because I'm getting lost myself ;) My main point is just that "retrieval" and "activation" are two unrelated things and trying to handle them together is a mistake (several comments on thin thread come to the same consideration). So I'd like to forget retrieval which is a lesser pressing problem and resolved with sequencing for most cases, for focusing on "activation". The main purpose of activation is saving bandwidth towards clients when going online. So the basic need is just cutting off inbound presence delivery for deactivated groups. This is quite simple: if nothing is specified all groups are "active"; at any instant I can specify a list of active groups and since that moment all inbound presence for unspecified groups is filtered. Then there is a second case that may become handy both for mobiles and a normal clients: partial invisibility. Now there is only the experimental xep 186, but it's a global "flag" setting invisibility for everybody. Since we're discussing about setting up a per roster group presence filter, I think that the mechanisms could be generalized in order to solve what appears the other side of the same problem. In order to approach both problems we need something symmetric for in and out presence and, more important, a way for telling the server which is the default behavior when nothing is specified for a group. So this what I'd like to see: - if nothing is specified, all is active as usual. - or the client can send a rule like this: <active> <default in="off" out="on"> <group in="on" out="on">vips</group> <group in="off" out="off"> losers</group> </active> The default element tells the server what to do for unspecified groups for both in and out presence, and the rule applies only for the active session (so no mess with other clients in different sessions). In this case we have the normal mobile situation in which we are visible to everybody and we don't receive incoming presence but for some groups. In particular we activate the "vips" groups for incoming presence. We also have a group of "losers" we don't want to know we are online when connected with a mobile, so we don't waste bandwidth for them ;) Later, during the same session, we become interested about the presence of one more group, "lesser vips", and we just send <active> <group in="on">lesser vips</group> </active> I think that this is extremely flexible and still simple for both developers and users... and, more important, limited to a given session, without side effects > Naturally, one way that people handle this kind of thing is simply to > have multiple accounts. I know I do that. :) We humans are quite > flexible regarding social solutions rather than technical solutions, and > having multiple accounts is a way to work around the fact that it's not > currently easy to do fancy views and activations regarding the roster. I think that is the geek way ;) Handling multiple accounts and subscriptions is a pain for most users. I prefer some general settings activated for all sessions, such as <active> <default in="off" out="on"> <group in="on" out="on">vips</group> </active> and then simple buttons on roster groups which can individually toggle in/out presence. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [email protected]
