Re: Proposal for multi-reference support in MTOM

Marc,

I think that if an application doesn't require or at least recommend an
optimization, it shouldn't know about it. And requiring an optimization
(or recommending it) seems wrong when there's a perfectly good alternate
design of the app that doesn't need the optimization.

Anyway, it wouldn't be an optimization any more if in order to support
it the application needed to add the optimization-specific attributes to
the application data.

I'm looking forward to the f2f minutes. 8-)

                   Jacek Kopecky

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



On Sun, 2003-11-30 at 16:23, Marc Hadley wrote:
> On 28 Nov 2003, at 10:55, Jacek Kopecky wrote:
> > What you're proposing is that your application know about a SOAP 
> > binding
> > optimization and rely on it.
> 
> No, I'm proposing that in addition to the 'send this stuff as binary 
> instead of base64' optimization there's an additional optimization: 
> 'these two chunks of base64 data are the same - just send one copy'.
> 
> 
> > I suggest that you extract the relevant
> > part of the optimization - called referencing - and incorporate it into
> > your application. If you're looking for a standard in this area, 
> > there's
> > XML Linking [1].
> 
> Thanks for the 'helpful' reference.
> 
> >  8-) I don't think the Representation header is
> > necessarily what you want.
> >
> > I see how the referencing part could be folded into the binding layer,
> > possibly eliminating some cases of references to other references on 
> > the
> > wire, but in doing so you limit your application to one optimization
> > technique and mandate that optimization (a mandatory optimization 
> > sounds
> > totally wrong). I think we should separate the concerns here into
> > different layers.
> >
> The optimization isn't mandated, if you want to ignore the hint and 
> send two or more copies of the data then nothing will break - it will 
> just be less efficient.
> 
> Marc.
>

Received on Tuesday, 2 December 2003 10:43:25 UTC