[JDEV] Promiscuous presence for user communities (with patch)

[Steven Brown]

> -----Original Message-----
> From: jdev-admin at jabber.org [mailto:jdev-admin at jabber.org] On 
> Behalf Of Richard Dobson
> Sent: Wednesday, October 01, 2003 9:20 AM
> To: jdev at jabber.org
> Subject: Re: [JDEV] Promiscuous presence for user communities 
> (with patch)
> 
> 
> > As to making changes to the Jabber protocol, I don't 
> understand all the
> > concern. I agree that it is always best to try to work 
> within a protocol,
> > but I thought that part of the point of open source 
> software is that you
> > could modify it "willy nilly" to meet your own needs. Generally not
> advised,
> > but sometimes the only option. I don't think that Steven 
> posted this as a
> > protocol change, but simply as a solution to this problem 
> for other people
> > like myself trying to do the same thing.
> 
> The point I think he was trying to make was that some of the 
> suggested best
> solutions were infact potensially dangerous to the rest of 
> the community
> because they broke the existing protocol rather than using extablished
> methods of extension that would not have been any real problem.
> 
> e.g.
> 
> <presence type="promiscuous"/>
> 
> This breaks existing protocol and could cause problems if 
> they come into
> contact with existing or future compliant implementations.
> 
> <presence>
>     <promiscuous xmlns="http://yourwebsite.com/jabber/promiscuous"/>
> </presence>
> 
> Whereas this uses the standard method of protocol extension 
> and should not
> cause any problems when coming into contact with standard compliant
> implementations.

I already had it doing such on the way out like is done for invisible
(to clients that might not understand it), but on the way in, I
implemented it just like invisible, too, which uses a type attribute.
It doesn't bother clients that don't understand it, as they just never
send that.  Peter pointed out that it'd be best to avoid implementing it
like invisible and instead send it just like it's received, and since
I'd eventually like this concept to be of use to more folks than just
me, I'll post a new patch when I get time to make the change.

> I think that the main problem is the seeming lack of caring and "willy
> nilly" approach that was used with creating the modification, 

I definately care and don't code willy nilly. :)  But, this is a custom
patch for custom use.  I posted it as it was obvious someone was running
into the exact same problem I had in making a custom solution.  In his
case, this can run completely under the hood and not be exposed to
clients at all, as it'd just be an engine for roster modifications.