Agent metadata

[bradphelan]

I'm a bit confused when state is referred to wrt to nanite. I would
like to store state for each nanite that is distributed to each
mapper. Imagine Zeroconf based on Nanite if you would.

Currently I have a home rolled system similar to Nanite. It uses the
amqp gem for messaging and couchdb for storing arbitrary metadata
about each agent/service. Services can be looked up by querying views
in couchdb. The services have methods notify_* which transmit AMQP
messages. It seems there is a lot of overlap with nanite and I would
prefer to ditch my homebrew solution for a community project if
possible.

Essentially my agent classes are a mashup of the
CouchRest::ExtendedDocument class and AMQP/EventMachine handlers. Can
Nanite do similar things.

Regards

Brad Phelan

--
You received this message because you are subscribed to the Google Groups "Nanite" group.
To post to this group, send email to nan...@googlegroups.com.
To unsubscribe from this group, send email to nanite+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nanite?hl=en.

[Mathias Meyer]

On Mon, May 3, 2010 at 11:42 PM, bradphelan <bradp...@gmail.com> wrote:
> I'm a bit confused when state is referred to wrt to nanite. I would
> like to store state for each nanite that is distributed to each
> mapper. Imagine Zeroconf based on Nanite if you would.
>
> Currently I have a home rolled system similar to Nanite. It uses the
> amqp gem for messaging and couchdb for storing arbitrary metadata
> about each agent/service. Services can be looked up by querying views
> in couchdb. The services have methods notify_* which transmit AMQP
> messages. It seems there is a lot of overlap with nanite and I would
> prefer to ditch my homebrew solution for a community project if
> possible.
>
> Essentially my agent classes are a mashup of the
> CouchRest::ExtendedDocument class and AMQP/EventMachine handlers. Can
> Nanite do similar things.
>

In terms of agent state in Nanite, the idea is pretty similar to
yours, except that data is stored in Redis on the mapper tier. Much
faster, much more lightweight. The data is constantly updated as
agents send their pings to the mappers, with services and some more
metadata being stored, so that a mapper can figure out where to send a
particular request coming in from e.g. your web tier.

You address agents using a URL, e.g. /task/do_it_fast, the mapper
looks up the agents offering that service and sends it right along. So
I'd say the ideas are pretty simple to yours from what I can gather.

Let me know if you need some more information, that's basically the gist of it.

Cheers, Mathias
--
http://paperplanes.de
http://twitter.com/roidrage