Your description of the push optimization potential is great, and I agree now. Thanks. Do you plan to implement this, or can I help in some way? Any idea of what timing makes sense? Thanks...PC
-----Original Message----- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Saturday, September 16, 2006 11:39 AM To: [email protected] Subject: Re: Binding Context? 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
