Re: [MTOM issue] OptimizationCandidates should be OptimizedElements

Mark,

I do intend the intermediaries to be able to change what is or is not
being optimized. Also, I believe that it is the responsibility of each
node in the message path to determine what is to be optimized by the
sending side of the node. IOW, in an environment where the optimization
occurs hop-by-hop, each hop prepares its own value of the property,
possibly based on what it received.

I'm saying that when the optimization is about to happen (which is
abstractly after the message is fully constructed and before it is
transmitted to the network) what we need is a set of elements to be
optimized, not just candidates. This is what an implementation of the
optimization feature will *certainly* need. Currently, though, we
provide a set of candidates which is the input to an implied selection
process that results in the actual optimized elements set, and we talk
no more about the selection process. I propose that the abstract feature
does not encompass the selection process and just takes its result, i.e.
OptimizedElements instead of OptimizationCandidates.

Hope it's clearer,

                   Jacek Kopecky

                   Senior Architect
                   Systinet Corporation
                   http://www.systinet.com/





On Thu, 2003-07-10 at 21:25, Mark Nottingham wrote:
> > On Thu, 2003-07-10 at 01:44, Mark Nottingham wrote:
> > > First of all, in the abstract feature, I'd rather keep it scoped to
> *any*
> > > information item; it shouldn't be restricted to elements (although a
> > > particular implementation of the feature may restrict to elements
> only,
> > > for example).
> >
> > I see that the abstract feature might be made even more abstract and be
> > able to optimize any information items. I don't know if we want to be
> > that abstract.
> 
> I agree that there are a number of ways that this could be packaged; we
> could have a generic "optimisation" feature, allowing properties to refine
> the nature of that optimisation; conversely, we could have a very specific
> "foo optimisation" feature, with properties that only parameterise that
> particular type of optimisation. Is there a best practice regarding this?
> 
> 
> > > > The reason for making the property a set of candidates is seemingly
> that
> > > > the binding may actually decide it knows better and not optimize
> > > > transmission of certain elements. What I'm saying is that in an
> > > > implementation, any piece of code can contribute to the value of the
> > > > property, including the code implementing the binding.
> > >
> > > If one is allowed to change them, it's still advisory, so I don't
> > > understand what's really changing here.
> >
> > What's changing here is that I propose we don't use something we don't
> > specify. I mean, if we have optimization candidates property, we're
> > basically saying there is this process (depending on the actual
> > implementation of the abstract feature) that may take into account the
> > value of this property and that results in the actual set of elements to
> > be optimized. We aren't going to formalize the process nor provide an
> > example of it in our spec.
> >
> > On the other hand, if we have optimized elements property, we skip the
> > whole selection process thingy which we don't specify much anyway. We
> > lose stuff we don't actually need. I would say I'm cutting some abstract
> > complexity away with Occam's razor.
> 
> You seem to be assuming that the decision about the optimisation is made
> by the original sender of the message, who by neccessity must have perfect
> knowledge of the entire message path and the capabilities of the nodes on
> it. I believe that there are a large number of use cases where this is not
> true.
> 
> 
> > > I think the semantic of the property is roughly this: "Here is a list
> of
> > > information items that someone who has seen this message before
> considered
> > > good candidates for optimisation style Foo. If you don't want to do
> the
> > > work to figure this out yourself when sending this message forward,
> this
> > > list is a pretty good starting point, although you may want to add
> and/or
> > > ignore items, for whatever reasons you might have."
> > >
> > > Note that this requires association with a specific style or type of
> > > optimisation, rather than just generic "optimisation," a subject that
> we
> > > touched on today.
> >
> > So we're saying
> > "we don't care how the user comes up with the actual list of elements to
> > be optimized, and we provide a vague pre-list in our property."
> >
> > What I'm proposing is saying
> > "we don't care how the user comes up with the actual list of elements to
> > be optimized, which he then puts in our property."
> 
> There has also been discussion of another property that reflects the
> portions of the message that are currently optimised, which I think is
> what you want.
> 
> Looking back, I'm a bit confused - do you intend to allow intermediaries
> to modify the property in transit?

Received on Friday, 11 July 2003 07:35:18 UTC