I am referring to consumer transient (and potentially persistent) information
hence the scope. I.e. a producer will commonly want to maintain per
consumer transient information at the scope of a consumer. Examples
might be per consumer logs, database pools, data daemons, consumer contexts,
etc. A producer needs a way to map from any given request back to
this per consumer data. I suspect this mapping will be enabled by
defining a key/handle such as a consumerCtx or registrationId. Hence
it will be implicit in the protocol as this key/handle will be required
on every call anyway and therefore can be used to maintain the mapping.
I suggest that though implicit we recognize and describe it as a useful/valid
scope.
In case you are wondering about this scope managing persistent information
as well. What I am thinking of here is we may decide that consumer
meta data passed to the producer (at registration time) needs to be persisted
if a producer wants to get back to it (so we don't have to always send
it). In this case I suspect that when (after server restarts)
a consumer comes back into scope this persistent information is read into
the transient information being managed at that scope.
On when you go into/out of consumer scope. Basically, you go into
scope as a side effect of any call that passes the registration/consumer
ID that currently isn't in scope. Going out of scope is defined by
the producer via timeouts/shutdowns or if a consumer deregisters with a
producer.
Does this help?
-Mike-
Gil Tayar wrote:
In
the interest of sanity and progress, I have broken up Rich's, Michael's,
Monica's and Eilon's emails into four subjects - "Shared Transient Information",
"Persistent Information Scope", "createEntity/createTemplate/createPortlet",
"session and entity handles", and "Property lists". This
email will deal with Persisent Information
Scope, and the relevant quotes from the emails and my reply
to them: Michael
wrote:>
2) I think the specification should recognize the per consumer scope. I> understand
a producer will be able to manage this scope transparently once we> add
a registration handle but I don't think that just because it can be> inferred
from the model we should ignore it (from the spec/description).> 3)
The definition of the "persistent information" type needs to be tightened.> As
written it implies a relationship with User transient information as both> are
claimed to be scoped to a user. Whereas a session is scoped one-to-one
to> a
user I don't believe persistent information is scoped one-to-one to a user.> Rather
I believe we have discussed situations where the mapping is 1 to N.> I.e.
the producer may be asked to operate on the sample persistent entity for> differing
concurrent user (sessions). This seems to imply that the scope of> "persistent
information" is whatever the consumer chooses it to be. So
now Gil writes:I
definitely agree on point #3. What I said was actually one Usage
of the persistent information (i.e. one use is to tie it to the user),
but yours is actually the more general - "the scope of
'persistent information' is whatever the Consumer chooses it to
be."Objections,
anybody? If not, I will change the draft spec appropriately.I
am unclear about Point #2 above. When you're saying the specification should
recognize the "per Consumer scope", you are talking about the scope on
what type of information (user transient, shared transient, or persistent)?
If it doesn't correlate to any type of information and is more of a general
comment, then can you please elaborate? (e.g. an example, a proposed change
to the spec)
