[Standards] Strictness of disco types
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 =~
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards