Oh, I also forgot one possible way (possibly the best): Protocol flow (excuse the shorthand):
Client: <message from="juliet" to="nurse/balance"><body>Send a nurse.</body></message> Nurse/Balance: <message from="juliet" to="nurse/Jill"><body>Send a nurse.</body></message> Nurse/Jill: <message from="nurse/Jill" to="juliet"><body>On her way.</body></message> This would allow each bot to service an entire request. A window would pop up with that bot's response - the user would most likely (via intuition) respond to that bot. One thing: a 'lazy' user could keep the nurse/Jill window open and send many requests to it, or they may close it and never be able to get back. Another option would be to (after the above flow has occurred): Client: <message from="juliet" to="nurse/balance"><body>Send a nurse</body></message> Nurse/Balance: <message from="nurse/balance" to="juliet"><body>You have a previous session with Jill. Continue?</body></message> Client: <message from="juliet" to="nurse/balance"><body></body></message> OR: <message from="juliet" to="nurse/balance"><body>Y</body></message> Nurse/Balance: <message from="juliet" to="nurse/Jill"><body>Send a nurse.</body></message> Nurse/Jill: <message from="nurse/Jill" to="juliet"><body>On her way.</body></message> Another route: Client: <message from="juliet" to="nurse/balance"><body>Send a nurse</body></message> Nurse/Balance: <message from="nurse/balance" to="juliet"><body>You have a previous session with Jill. Continue?</body></message> Client: <message from="juliet" to="nurse/balance"><body>N</body></message> Nurse/Balance: <message from="juliet" to="nurse/Jane"><body>Send a nurse.</body></message> Nurse/Jill: <message from="nurse/Jane" to="juliet"><body>On her way.</body></message> HTH > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Jonathan Dickinson > Sent: 18 June 2008 02:08 PM > To: Jabber/XMPP software development list > Subject: Re: [jdev] xmpp4r component development > > Hey Adam, > > A load-balancable bot? I assume that means that your chatbot can have x > amounts of real contacts. > > The XMPP specs would indicate that you would need to give each a separate > resource. One idea (not 100% XMPP compliant): since components can alter > user's rosters how about providing the user with a new roster item every time > they log in - this roster item would be one of the bots. E.g. > > Login 1: > > Juliet's Contact List > --------------------- > [EMAIL PROTECTED]/jill > > Login 2: > > Juliet's Contact List > --------------------- > [EMAIL PROTECTED]/jane > > The problem with that is Juliet may never communicate with the bot, as such it > 'goes to waste' and one bot may be servicing requests alone (in the worst > case). But it is a clean implementation. > > Another option would be to route all requests as follows: > > Client connections ---> server ---> [EMAIL PROTECTED] ---> jill, jane > > You would need to persist the contact's state between the bots, so you have a > few options with that as well (===> indicates state info): > > Jill and Jane communicate with [EMAIL PROTECTED] to gather state. > Client connections ---> server ---> [EMAIL PROTECTED] ---> jill, jane > V================^=====^ > Or > > Jill and Jane communicate with database to gather state. > Client connections ---> server ---> [EMAIL PROTECTED] ---> jill, jane > ^=====^===== > Database > > Finally, you can have the contact contain all the state for each contact. And > send it along with each request. The flow would be: > > Cl == client (Juliet) > Co == component ([EMAIL PROTECTED]) > B1 == bot1 ([EMAIL PROTECTED]) > B2 == bot2 ([EMAIL PROTECTED]) > > Cl ---> Co: <message><body>Yes, send a nurse.</body></message> > Co ---> B1: <message><body>Yes, send a > nurse.</body><state><nurseRequested/></state></message> > B1 ---> Co: <message><body>Nurse > sent.</body><state><nurseSent/></state></message> > Co ---> Cl: <message><body>Nurse sent.</body></message> > > Cl ---> Co: <message><body>Send a nurse</body></message> > Co ---> B2: <message><body>Send a > nurse.</body><state><nurseSent/></state></message> > B2 ---> Co: <message><body>Nurse already > sent.</body><state><nurseSent/></state></message> > Co ---> Cl: <message><body>Nurse already sent.</body></message> > > B1 ---> Co: <message><body>Nurse at your door.</body><state/></message> > Co ---> Cl: <message><body>Nurse at your door</body></message> > > Cl ---> Co: <message><body>Send a nurse.</body></message> > Co ---> B1: <message><body>Send a nurse.</body><state/></message> > B1 ---> Co: <message><body>Are you > sure?</body><state><nurseRequested/></state></message> > Co ---> Cl: <message><body>Are you sure?</body></message> > > > I am sure you get the idea. Is this what you were after? > > Jonathan > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > > Adam Pisoni > > Sent: 17 June 2008 05:38 PM > > To: Jabber/XMPP software development list > > Subject: [jdev] xmpp4r component development > > > > Hola. I'm a newcomer at this list, but friends with Anders and > > Blaine. I'll also be at the summit this year. I'm working on a, > > still under wraps, project for Geni.com that involves heavy xmpp > > development. Currently I'm working on a xmpp4r component to serve as > > the gateway between our application and 'the world'. I would say my > > component is acting like a glorified, load balance-able bot, but it's > > a bit more than that. There's not a lot of information out there on > > components in general and even less on writing components with > > xmpp4r. We've made tremendous progress, however , thanks to help from > > Anders and Blaine, as well as lots of trial and error. We're well on > > our way towards building a general xmpp4r component framework that is > > analogous to xmpp4r-simple, but for component development. > > > > The good news is that we will be open sourcing this component > > framework so that others can benefit. This will probably be the > > first of a number of pieces in development that we will be open > > sourcing. We realize that the xmpp community is still in its infancy > > and as such, everyone, including ourselves, benefits when we all > > share. That said, I'm curious if anyone else out there has had much > > experience building these types of components, especially with xmpp4r, > > and would like to exchange notes. I am also hoping to share some of > > my design decisions to solicit some feedback. > > > > So, anyone want to exchange war stories? > > > > Thanks, > > adam > > _______________________________________________ > > JDev mailing list > > FAQ: http://www.jabber.org/discussion-lists/jdev-faq > > Forum: http://www.jabberforum.org/forumdisplay.php?f=20 > > Info: http://mail.jabber.org/mailman/listinfo/jdev > > Unsubscribe: [EMAIL PROTECTED] > > _______________________________________________ > _______________________________________________ > JDev mailing list > FAQ: http://www.jabber.org/discussion-lists/jdev-faq > Forum: http://www.jabberforum.org/forumdisplay.php?f=20 > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: [EMAIL PROTECTED] > _______________________________________________ _______________________________________________ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] _______________________________________________
