Re: [MTOM issue] OptimizationCandidates should be OptimizedElements

Mark,

thanks for you response. My replies inline.

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.

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

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

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

Less vagueness, same function, same potential.

                   Jacek Kopecky

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

Received on Thursday, 10 July 2003 03:46:12 UTC