Re: [Embedlets-dev] [Arch] Re: Persistence vs. Management

[Brill P. <bri...@ro...>]

> The fallacy here (in my mind) is thinking that Embedlets should be
persisted.  I
> don't think there are some issues with that.  If you look at a servlet
(probably
> the closest analogy to what I think an Embedlet should look like), you
might
> persist the context (Container, application or Embedlet contexts in
particular),
> but not the Embedlet itself.

So you saying the embedlet should be a simple endpoint, only called when the
container thinks it has something to contribute...

I think I'd agree with that.

> The reason for this has to do with making threading more easily
implemented
> and managed by the container.  So with servlets, you don't use instance

I'd narrow that down a little I think... for the most part an Embedlet would
be talking to/gathering data from a single device, so maybe the embedlet
should be a singleton... also helps reduce load on the embedded environment
by not trying to do to much at once. Of course, that assumes the embedlet
endpoint can do what it needs to do quickly and lets go of the resources its
might be holding to do that task.

For instance, on the physical level in Cork, only one device can be talking
over I2C at any one time, so the underlying code allows the bus to be
"locked" for any other requests, it also takes the addresses of the
available devices into account because you can't have more than one with the
same address (in certain circumstances you can, but in that case it would be
the same device as far as the software was concerned).

Anyway, I don't think its really required that the embedlets behave that
way, as the container can do the work of requesting data as needed...
however the embedlet should take into account that the container can only do
things one at a time (for the most part). Anyway, quick, low traffic
requests are important here.

The other option of course is to dump the data elsewhere (into a DB maybe)
and allow the embedlet to redirect requests, or be used only for outgoing
transmission (and not service requests on its own).

- Brill