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
smime.p7s
Description: S/MIME Cryptographic Signature
