On 14 January 2015 at 05:57, David Bolack <dbol...@missingworldsmedia.com> wrote:
> > On Monday, January 12, 2015 03:14 EST, Dave Cridland <d...@cridland.net> > wrote: > > > In general, proposing a XEP that's rejected because it's a terrible idea > > adds more value than doing something that's a terrible idea without > > discussing it. Even if you choose not to go as far as a formal protoXEP, > > it'll hopefully be useful to all parties. > > Bear in mind, I've never attempted a standards body draft of anything, so > here's the general ideas. > > We're going to use XMPP for internal coms for a game. As such, users have > both a global and an instance identity and should be reachable by either > the global name ( at all times when logged in ) and the active > instance/character name. And we intend to use MUC as a "channel" analog. > > So there's the player's login name - jid - and a character name. I understand what you've written to mean there's only one active character (though there may be multiple characters). > With our own clients, this is easy to control, we can enforce the MUC > Nicknames to the character name, etc, but I've been asked to make sure that > standard, third party XMPP clients can hook in as well. This complicates > things slightly. :) > > Well, you can enforce nicknames using standard clients too. Either just rejecting the join, or responding with a different nickname - the latter I've not actually seen in production, but in principle it should work. I suspect the more difficult part would be indicating the currently active character. > The best solution I have come up with is: > > Use the resource id to identify the character > Resource ids are opaque; I think trying to ascribe meaning to them is likely to cause heartache and pain. Aside from anything else, you'll break multi-device. > Have the authentication method verify user ( node ) and character ( > resource id ) against the login password > Have the MUC code force the room nick for the user to the Resouce ID. ( > and I'm dubious we can control that in a third party app ) > > But again, I'm not sure if ( assuming the above is all functionally > possible ) that a XEP is appropriate. > In order to do this, you've got to control the entire XMPP server; I think that's going to cost you in the long term. Most servers allow you to have custom authenticators, but very few allow fine control over the resource id. Obviously if you use an open-source server as your base, you can do whatever you like, but I suspect the merge costs will be significant. Instead, I think you want to stick with a customized MUC component/plugin, and a custom authenticator (and that only if you *really* need it). For the current character, you could just do another custom component that simply tracks the current character selected. You could have an ad-hoc interface for character selection to support third-party clients, and some way of querying for the MUC component (unless it just handles that internally). I think if you did that, your engineering costs would be reasonably low, and you'd get multi-device, third-party client support - in particular mobile. Dave.
