[jdev] Enterprise Instant Messaging Developer

[Wagner, Zanaya]

Hi all-

I just wanted to reach out regarding an Instant Messaging Opportunity we have available here at our firm. Susquehanna International Group is one of the largest privately held financial institutions in the world, and we are currently interested in bringing new talent to our technology division. You can visit our website at www.sig.com<http://www.sig.com/> to learn more about our company and this position. I've included the job description in this e-mail as well. If you are interested or know anyone interested in applying, please feel free to either e-mail me at zanaya.wagner (AT) sig (DOT) com<mailto:zanaya.wagner (AT) sig (DOT) com> or call 610-617-2896. Let me know if you have any questions. Thanks so much!

Sincerely-

Zanaya Wagner
Internet Research Specialist
Susquehanna Internation Group, LLP
Phone: 610-617-2896
E-mail: zanaya.wagner (AT) sig (DOT) com<mailto:zanaya.wagner (AT) sig (DOT) com>
www.sig.com<http://www.sig.com>

P Please consider the impact to our environment before printing this e-mail.


________________________________
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Adam Pisoni]

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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Jonathan Dickinson]

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
---------------------
nurse (AT) acmenurse (DOT) org/jill

Login 2:

Juliet's Contact List
---------------------
nurse (AT) acmenurse (DOT) org/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 ---> nurse (AT) acmenurse (DOT) org ---> 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 nurse (AT) acmenurse (DOT) org to gather state.
Client connections ---> server ---> nurse (AT) acmenurse (DOT) org ---> jill, jane
V================^=====^
Or

Jill and Jane communicate with database to gather state.
Client connections ---> server ---> nurse (AT) acmenurse (DOT) org ---> 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 (Nurse (AT) acmenurse (DOT) org)
B1 == bot1 (Nurse (AT) acmenurse (DOT) org)
B2 == bot2 (Nurse (AT) acmenurse (DOT) org)

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: jdev-bounces (AT) jabber (DOT) org [mailto:jdev-bounces (AT) jabber (DOT) org] 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: JDev-unsubscribe (AT) jabber (DOT) org
> _______________________________________________
_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Jonathan Dickinson]

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: jdev-bounces (AT) jabber (DOT) org [mailto:jdev-bounces (AT) jabber (DOT) org] 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
> ---------------------
> nurse (AT) acmenurse (DOT) org/jill
>
> Login 2:
>
> Juliet's Contact List
> ---------------------
> nurse (AT) acmenurse (DOT) org/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 ---> nurse (AT) acmenurse (DOT) org ---> 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 nurse (AT) acmenurse (DOT) org to gather state.
> Client connections ---> server ---> nurse (AT) acmenurse (DOT) org ---> jill, jane
> V================^=====^
> Or
>
> Jill and Jane communicate with database to gather state.
> Client connections ---> server ---> nurse (AT) acmenurse (DOT) org ---> 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 (Nurse (AT) acmenurse (DOT) org)
> B1 == bot1 (Nurse (AT) acmenurse (DOT) org)
> B2 == bot2 (Nurse (AT) acmenurse (DOT) org)
>
> 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: jdev-bounces (AT) jabber (DOT) org [mailto:jdev-bounces (AT) jabber (DOT) org] 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: JDev-unsubscribe (AT) jabber (DOT) org
> > _______________________________________________
> _______________________________________________
> 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: JDev-unsubscribe (AT) jabber (DOT) org
> _______________________________________________
_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Peter Saint-Andre]

On 06/18/2008 6:07 AM, Jonathan Dickinson wrote:
> Hey Adam,
>
> A load-balancable bot? I assume that means that your chatbot can have x amounts of real contacts.

He may mean something like twitter (AT) twitter (DOT) com or jaiku (AT) jaiku (DOT) com. Often
people start out writing those as bots but then they find that the bot
doesn't scale up to 10,000 contacts so they convert it to a component.
Perhaps the Gnip folks plan to make that transition easier or even
unnecessary in the first place. Pure speculation. :)

Peter

--
Peter Saint-Andre
https://stpeter.im/


_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Pedro Melo]

Hi,

On Jun 18, 2008, at 1:28 PM, Peter Saint-Andre wrote:

> On 06/18/2008 6:07 AM, Jonathan Dickinson wrote:
>> Hey Adam,
>>
>> A load-balancable bot? I assume that means that your chatbot can
>> have x amounts of real contacts.
>
> He may mean something like twitter (AT) twitter (DOT) com or jaiku (AT) jaiku (DOT) com.
> Often
> people start out writing those as bots but then they find that the bot
> doesn't scale up to 10,000 contacts so they convert it to a component.
> Perhaps the Gnip folks plan to make that transition easier or even
> unnecessary in the first place. Pure speculation. :)

I missed the original message but this would be my recomendation too.

I know of a system, 5 external components load-balanced using
ejabberd domain_balance stuff that represents about 500k virtual
users each with 10 to 15 buddies avg.

external components are the way to go to implement large scale bots.

Best regards,
--
HIId: Pedro Melo
SMTP: melo (AT) co (DOT) sapo.pt
XMPP: pedro.melo (AT) sapo (DOT) pt


_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Adam Pisoni]

Yeah, my specific component represents 1 (or a few) bots which
themselves may have extremely large rosters. So writing it as a
component allows me to control the whole roster/presence process in a
scaleable, fault-tolerant way. I'm using ejabberd to back it up.

Though again, the goal is to create a general framework that makes
component (not necessarily bot) creation easy... or at least
easier. It will probably never be as easy as writing a simple
client using xmpp4r-simple, but at least you won't have to reinvent
the wheel... as I'm having to do.

Who are the gnip folks and what are they doing that is so relevant?

adam



On Jun 18, 2008, at 5:28 AM, Peter Saint-Andre wrote:

> On 06/18/2008 6:07 AM, Jonathan Dickinson wrote:
>> Hey Adam,
>>
>> A load-balancable bot? I assume that means that your chatbot can
>> have x amounts of real contacts.
>
> He may mean something like twitter (AT) twitter (DOT) com or jaiku (AT) jaiku (DOT) com.
> Often
> people start out writing those as bots but then they find that the bot
> doesn't scale up to 10,000 contacts so they convert it to a component.
> Perhaps the Gnip folks plan to make that transition easier or even
> unnecessary in the first place. Pure speculation. :)
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
> _______________________________________________
> 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: JDev-unsubscribe (AT) jabber (DOT) org
> _______________________________________________

_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Adam Pisoni]

I learned the same lesson... External components require a LOT more
work to set up, but give you a lot more flexibility and options for
scaling. That said, there just isn't a lot of information out there
as to people's experiences building these thins. Which is why I'm
trying to create a more general framework that others can use.

Thanks,
adam

On Jun 18, 2008, at 9:46 AM, Pedro Melo wrote:

> Hi,
>
> On Jun 18, 2008, at 1:28 PM, Peter Saint-Andre wrote:
>
>> On 06/18/2008 6:07 AM, Jonathan Dickinson wrote:
>>> Hey Adam,
>>>
>>> A load-balancable bot? I assume that means that your chatbot can
>>> have x amounts of real contacts.
>>
>> He may mean something like twitter (AT) twitter (DOT) com or jaiku (AT) jaiku (DOT) com.
>> Often
>> people start out writing those as bots but then they find that the
>> bot
>> doesn't scale up to 10,000 contacts so they convert it to a
>> component.
>> Perhaps the Gnip folks plan to make that transition easier or even
>> unnecessary in the first place. Pure speculation. :)
>
> I missed the original message but this would be my recomendation too.
>
> I know of a system, 5 external components load-balanced using
> ejabberd domain_balance stuff that represents about 500k virtual
> users each with 10 to 15 buddies avg.
>
> external components are the way to go to implement large scale bots.
>
> Best regards,
> --
> HIId: Pedro Melo
> SMTP: melo (AT) co (DOT) sapo.pt
> XMPP: pedro.melo (AT) sapo (DOT) pt
>
>
> _______________________________________________
> 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: JDev-unsubscribe (AT) jabber (DOT) org
> _______________________________________________

_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Peter Saint-Andre]

On 06/18/2008 10:59 AM, Adam Pisoni wrote:
> Yeah, my specific component represents 1 (or a few) bots which
> themselves may have extremely large rosters. So writing it as a
> component allows me to control the whole roster/presence process in a
> scaleable, fault-tolerant way. I'm using ejabberd to back it up.
>
> Though again, the goal is to create a general framework that makes
> component (not necessarily bot) creation easy... or at least
> easier. It will probably never be as easy as writing a simple
> client using xmpp4r-simple, but at least you won't have to reinvent
> the wheel... as I'm having to do.
>
> Who are the gnip folks and what are they doing that is so relevant?

Sorry, I got you confused with these folks:

http://gnipcentral.com/

That's what I get for scanning emails at 6 in the morning...

P

--
Peter Saint-Andre
https://stpeter.im/


_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Adam Pisoni]

I'm not sure I get what you're saying. First of all the components do
not need resources per se. I can run as many components AS the same
component jid (chat.whatever.com) as I want. ejabberd round robins
sending ALL stanzas which are addressed TO
ANYTHING (AT) chat (DOT) whatever.com. It is up to the component to deal with
session management, presence, etc... In my case my component is only
fronting a single user with a massive roster and sending messages FROM
that user to users on other systems including AIM (via pyaimt). So I
don't currently have to deal with different rosters for different
users... though one of my design goals WAS handling just that.

Does that make sense?

Thanks,
adam



On Jun 18, 2008, at 5:07 AM, Jonathan Dickinson wrote:

> 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
> ---------------------
> nurse (AT) acmenurse (DOT) org/jill
>
> Login 2:
>
> Juliet's Contact List
> ---------------------
> nurse (AT) acmenurse (DOT) org/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 ---> nurse (AT) acmenurse (DOT) org ---> 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 nurse (AT) acmenurse (DOT) org to gather state.
> Client connections ---> server ---> nurse (AT) acmenurse (DOT) org ---> jill,
> jane
> V================^=====^
> Or
>
> Jill and Jane communicate with database to gather state.
> Client connections ---> server ---> nurse (AT) acmenurse (DOT) org ---> 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 (Nurse (AT) acmenurse (DOT) org)
> B1 == bot1 (Nurse (AT) acmenurse (DOT) org)
> B2 == bot2 (Nurse (AT) acmenurse (DOT) org)
>
> 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: jdev-bounces (AT) jabber (DOT) org [mailto:jdev-bounces (AT) jabber (DOT) org] 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: JDev-unsubscribe (AT) jabber (DOT) org
>> _______________________________________________
> _______________________________________________
> 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: JDev-unsubscribe (AT) jabber (DOT) org
> _______________________________________________

_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Adam Pisoni]

What are they doing?

adam

On Jun 18, 2008, at 10:05 AM, Peter Saint-Andre wrote:

> On 06/18/2008 10:59 AM, Adam Pisoni wrote:
>> Yeah, my specific component represents 1 (or a few) bots which
>> themselves may have extremely large rosters. So writing it as a
>> component allows me to control the whole roster/presence process in a
>> scaleable, fault-tolerant way. I'm using ejabberd to back it up.
>>
>> Though again, the goal is to create a general framework that makes
>> component (not necessarily bot) creation easy... or at least
>> easier. It will probably never be as easy as writing a simple
>> client using xmpp4r-simple, but at least you won't have to reinvent
>> the wheel... as I'm having to do.
>>
>> Who are the gnip folks and what are they doing that is so relevant?
>
> Sorry, I got you confused with these folks:
>
> http://gnipcentral.com/
>
> That's what I get for scanning emails at 6 in the morning...
>
> P
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
> _______________________________________________
> 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: JDev-unsubscribe (AT) jabber (DOT) org
> _______________________________________________

_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Peter Saint-Andre]

On 06/18/2008 11:08 AM, Adam Pisoni wrote:
> What are they doing?

I'm not sure really, but Eric Marcoullier and/or Jud Valeski from Gnip
will be at the XMPP Summit, so you'll be able to ask them in person. :)

Peter

--
Peter Saint-Andre
https://stpeter.im/


_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[anders conbere]

On Wed, Jun 18, 2008 at 10:11 AM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im> wrote:
> On 06/18/2008 11:08 AM, Adam Pisoni wrote:
>> What are they doing?
>
> I'm not sure really, but Eric Marcoullier and/or Jud Valeski from Gnip
> will be at the XMPP Summit, so you'll be able to ask them in person. :)

Their site is very ... secretive.

~ Anders

>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> _______________________________________________
> 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: JDev-unsubscribe (AT) jabber (DOT) org
> _______________________________________________
>
>
_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Stephan Maka]

Adam Pisoni wrote:
> our way towards building a general xmpp4r component framework that is
> analogous to xmpp4r-simple, but for component development.

Have you thought about contributing this framework as a part of XMPP4R?
Should be convenient now that it is being developed at GitHub.

_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________

[Adam Pisoni]

Yes I have. I figure I'll work on it with everyone first and if the
community thinks it makes sense, that's what I'll do. This is very
much uncharted territory. People have created one off components, but
there are no general component frameworks. I'm sure each one-off has
implemented things in their specific way and left a lot out. I'll
definitely have something to show by the Summit and I'm hoping to have
something much earlier than that.

Thanks,
adam



On Jun 19, 2008, at 9:18 PM, Stephan Maka wrote:

> Adam Pisoni wrote:
>> our way towards building a general xmpp4r component framework that is
>> analogous to xmpp4r-simple, but for component development.
>
> Have you thought about contributing this framework as a part of
> XMPP4R?
> Should be convenient now that it is being developed at GitHub.
>
> _______________________________________________
> 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: JDev-unsubscribe (AT) jabber (DOT) org
> _______________________________________________

_______________________________________________
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: JDev-unsubscribe (AT) jabber (DOT) org
_______________________________________________