Hi Mats, The reason for this is two-fold - one was to find who wants browse to still be active, the other was because I want to get browse right before re-activating it. You may notice that the configuration you have to put in the browse section of the jabber.xml file differs from the other examples in there (ie I use an item tag, others use a service or conference tag). This is because I am aiming to comply with the browse jep as it stands, following the spirit where a case is not clear. If i'm not doing it right inside the service, then i'd rather rip out the bad code and work in the new code in a better fashion. I'm already worried about supporting unicode node names, as i'm trying to find a C library I can use to give me the functions I need. We need a stable definition of a node name, along with a reference of how this can be achieved, I still recall JEP-0029, where it was stated that the node should have its case preserved, but be case-normalized for comparison. No-one was supporting that, even the jabberd server itself.
I may have to break down and learn C++, so I can recode MU-Conference and make use of any better unicode support and/or libraries, especially in light of the recent speed increases in C++ code. I've avoided doing so up till now as I felt it would be best to finish what I have before moving onwards. Regards, David On Fri, Feb 14, 2003 at 02:19:38PM +0100, Mats Bengtsson wrote: > > David Sutton wrote: > > In view of the recent discussion, support for browse has been dropped in > > MU-Conference cvs code, ready for when the disco protocol goes draft. > > David, > > I think this decision is very unfortunate, if I may speak for > the client developers. I guess many have built some browse UI > for use with jabber:iq:conference that is very practical > to reuse when testing out the MUC protocol. > I agree that support for jabber:iq:browse should only be considered > temporary, and later phased out and replaced by disco. > But meanwhile, keep some sort of support for browse, at least as > a help in assisting client developers testing MUC. > > > made it more complicated to retrieve the data necessary. What I may do > > is make browse an optional extra which can be enabled or disabled at the > > service admins choice. If I do this, then the SHA hash idea (for > > representing a users true jid, not roster entry) may also be an option. > > I really perceive this being of use in certain situations, even if > > others may not yet. > > Sounds like a reasonable compromise to me. > > Hope this post is not completely out of sync... > > Best Wishes, Mats > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev -- David Sutton Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
