What I am trying to do is to extend your "game matching service" in a
"game matching and creating service" : a client may request to create
new game
hosts. So I would like the "game matching and creating service" to
instantiate
game hosts with their JIDs and specific parameters, and I don't know
how to do that : I thought an internal component was loaded at server
start
according to its configuration file, so I guess my dynamic game hosts
can not
be internal components... ?
I would advise against putting "game host" functionality (i.e. creating)
into the "game matching service", the matching service should only
really be there so you can locate game hosts, if I am understanding your
reasons for wanting to do this correctly you want to only start up the
game hosts when someone first accesses it, but personally I think that's
the wrong way to go about it, the game hosts should be already running
at the point someone wants to start a game, so would be better to start
them up when you start the component/server up.
If this is right, the alternative may be that the
"game matching and creating service" launches an external script (e.
g. a php
script on another web server) that creates a new daemon bot and
register it
as the game host. What's weird in that case is that this communication
(launching
the php script) is outside the Jabber protocol.
Sounds like purely an implementation issue to me, it doesn't matter if
they are started outside of the protocol, as long as they are already
running by the time people come to ask them to start a game.
Norman, you suggest another seductive solution, but it looks to me
that it
implies a modification of the server source code, and the way it
implements MUCs.
What he suggests means its then not possible using the same protocol to
have games without a server being involved as some people have stated is
a requirement in past discussions about this, so its pretty much a non
starter unfortunately.
Richard
