Hi Dave,
I think Moffitt was pitching this model to me over lunch a few moons
ago. Moreover, I believe we concluded that this is not a good model
because it requires people that want to run farms to have server
access (running their own XMPP server) ??
With Linked Process, we want any "Joe Schmo" to be able to run a farm
and allow people to use their laptop/cellphone/desktop/etc. to compute
with. We want people to be able to use their gmail GTalk, jabber, etc.
accounts as well---i.e. ride atop existing XMPP servers/networks. We
want to make it as easy as possible for anyone to throw up a farm (in
fact, hopefully, just have Linked Process as a background thread on as
many machines as possible.)
In this respect, I think, though I'm not hyper-confident (Jack please
fill in if you remember the context), that your model of
farm.example.com/someidentifier requires that the farm provider have
admin access to the underlying XMPP server at example.com. Thus, to
run a farm means that you are running/admin'ing an XMPP server.
Given this realization (if its true), I saw fit to make a Farm a
"standard" XMPP client -- as simple as a chat client.
Thoughts?
Marko.
http://markorodriguez.com
On Sep 30, 2009, at 3:49 PM, Dave Cridland wrote:
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
