Re: [MTOM issue] OptimizationCandidates should be OptimizedElements

> 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 Thursday, 10 July 2003 15:46:09 UTC