On Wed Sep 30 18:26:54 2009, Marko A. Rodriguez wrote:
In short, the "environmentid" is needed to state to which
environment you are altering the state of (which VM you are
altering the state of). While this could be in the "to=" of the IQ
tag, the farm is the only XMPP client in the architecture (much
faster/efficient to create virtual machines without having to log
them into an XMPP server and flood the network with <presence/> --
and no server components wanted.). Or it could be in the "<code/>"
tag -- e.g. <code vm_id="VM-1234"/>??. What are you thoughts on
this "routing" issue?
Two comments.
Firstly, yes, you could stick it as a part of the data. You can stick
*anything* as part of the data, and you get to define what it looks
like and what it means, so this is the logical place for it.
Secondly, I'm pretty sure you should be modelling this as a
component, so a farm becomes, say, farm.example.com, with VMs as
[email protected] - or possibly
farm.example.com/someidentifier.
I'd probably opt for the latter - it allows a single presence
subscription (to farm.example.com) to be used to easily process
presence between clients and relevent VMs, without cluttering up the
model.
So, my account could have a subscription to farm.example.com, but
farm.example.com responds to probes by delivering me presence of only
those of its resources that model VMs that I actually own.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
