On Sep 16, 2006, at 7:48 AM, Peter Cousins wrote:
I was thinking application components would receive the information
using push, which seems to be what you're thinking.
Yes.
I was thinking that the aspect components could access the context
information using pull, because their behavior is dynamic and
potentially difficult to expose deterministically. By this I mean the
purpose is to algorithmically inspect the execution context and
expose a
simpler model that can be pushed. Concretely casting the raw
information into a push based interface seems unnecessarily brittle
and
expensive.
Conversely, I would think algorithmically inspecting the execution
context to dynamically determine behaviour seems expensive to me. We
definitely want to allow that, but I would like to know from a
dynamic component what the data set is that its algorithm needs and
ideally what the execution cost is. Those become metadata that can be
used by the fabric to choose which implementation of an aspect it
should engage.
For example, there is a cost incurred to construct the input data
set. It may be raw I/O cost to read the physical data, parse cost of
message headers either in HTTP form or XML, parse cost of payload
data, and so forth. The fully dynamic case where the component
basically says "I might access anything you have" requires us to
parse the entire stream (a processing cost) and retain the result (a
memory cost); on the other hand a more documented component that
declares which HTTP headers or XML paths its algorithm uses provides
more information the fabric can use optimize the pre-invocation
processing.
A simple implementation may choose to parse/retain everything anyway;
however, a more sophisticated implementation may be able to optimize
this step. What's important to me is we define a model that allows
this kind of optimization by the fabric controller.
By the way, doesn't the requirement for managed context extensibility
seem somehow similar to the requirement for extensibility of
configuration stream readers?
I see one big difference in that configuration readers run relatively
infrequently whereas context is accessed on every request. We can get
away with dynamic algorithms etc. in the configuration case but when
it comes to processing a runtime requests we want to be able to
optimize to the shortest path.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
