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.
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. If you or anyone have other thoughts on this though, I'd love to hear them. Daniel ----- "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote: > Daniel Henninger wrote: > > http://www.xmpp.org/registrar/disco-categories.html#conference > > > > So there are two types listed. text and irc. Are these meant to > be > > strict type choices, or suggestions? Is it theoretically bad to > use > > something other than those two choices? > > The reasons for some of the service discovery identities are lost in > the > mists of time. From the XMPP perspective the "conference/irc" type is > probably better described as "gateway/irc", because IRC simply is a > text > conferencing technology. And a text chat room that simultaneously > functions as a MUC room and an interface to an IRC channel should > probably have two identities: "conference/text" and "gateway/irc". > > The XMPP Registrar would be happy to update the registrations if > requested. :) > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/
