Re: [MTOM issue] OptimizationCandidates should be OptimizedElements

> I think that in the abstract, the property that our Abstract
> Transmission Optimization Feature would use better would be a set of
> (pointers to) the elements that are *to be optimized*, not just a set of
> candidates.

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).


> 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.


> If we keep OptimizationCandidates with thee current semantics, we are
> implicitly providing (at least on the sending node) another piece of
> information - the set of elements that were considered optimization
> candidates but weren't actually optimized. What do we need this
> information for? Some people actually seem to think this piece of
> information might be transferred to the receiving node, which introduces
> more implementation complexity. Why?

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.


Cheers,

Received on Thursday, 10 July 2003 00:54:31 UTC