[Standards] Strictness of disco types

Peter Saint-Andre stpeter at stpeter.im
Sat Mar 8 15:07:47 UTC 2008


Daniel Henninger wrote:
> Hi Peter!
> 
> My only concern with that route is, you start getting into having to
> account for a lot.  Lets say you are only looking for conferences of
> type text with no additional features.  In other words, you want "the
> conference service" provided by your server.  Now you have to parse
> through all of the conference services going "hrm, I don't want ones
> that are also of type gateway".  "oh someone created a new feature
> where you can have conference/text and conference/voice, crap, i
> don't want that one either, gotta update my client to account for
> that".  That said, is conference/text vs conference/irc vs
> gateway/irc vs whatever the right way to go there?  Hard to tell.

An entity can have multiple identities. So a text conferencing server
that simultaneously acts as a gateway to IRC can return this:

<identity category='conference' type='text'/>
<identity category='gateway' type='irc'/>

So if you're looking for XMPP text conferencing services because you
want to chat about certain topics, you just look for conference/text
services. The fact that it's also an IRC gateway is simply icing on the
cake. But if you want to join a particular IRC channel from a particular
IRC network (say #debian on freenode) then you need to know that the
text conferencing service can enable you to get to that room. I don't
know if any of the IRC gateways provide that level of detail.

> So let me bring the discussion backwards a little bit.  How would you
> deal with this issue from a client perspective in a way that didn't
> mean you had to keep tabs on such additions and keep eliminating more
> and more things?
> 
> To provide a specific scenario, Spark has a feature where, if you are
> chatting with another person privately, you can click a button and
> auto-create a group chat (username_XXXX where XXXX is a random
> string), which auto-invites the person you were talking to, and also
> then allows you to invite other people.  It's pretty handy, but it
> depends on knowing what the primary conference service on the server
> is.  Otherwise you get into confusing users with "what service do you
> want to use?"  "hell if i know!"  ;)   More importantly, if you had
> seen a gateway related conference service, most likely that wont work
> with this because XMPP to XMPP via IRC ... well frankly would be
> silly.  ;)  Lets not get into the details of what happens if you ARE
> talking to an IRC person and do an instant chat.  I'm just trying to
> conceptually find a way to weed out conference services that aren't
> going to suit your needs.
> 
> The more I think about it, the more I'm starting to think that maybe
> the proper way to handle this would be to scan the MUC features of
> every conference service and eliminate based off that.  Something
> like, this functionality requires: muc_open muc_temporary if (also
> has gateway/whatever) also require being logged into $servicejid =~
> s/conference.//
> 
> Hell I may have just solved my query by typing this out.  =/  I still
> think conference/irc should be retired though.  =)  I think it's a
> little misleading/confusion.  For now I think we only have
> conference/text and that seems fair.

Agreed. I think gateway/irc might be valuable as additional information
but the primary data of interest is conference/text.

/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080308/639c5829/attachment.bin>


More information about the Standards mailing list