Re: Optimization Mechanism description (was PASWA Feature Description)

Mark, please see inside, and forgive my taking so long to reply.

On Mon, 2003-06-30 at 15:11, Mark Nottingham wrote:
> > I don't like the idea
> > that this property is just a hint - on the implementation level it
> > doesn't matter and on the abstract level we have to care about what the
> > hint-ness of the property means.
> 
> Optimisation by its nature is optional, therefore it's more sensible (and
> flexible, forgiving, and potentially efficient) to make it a declarative
> hint rather than an imperative processing instruction.
> 
> For example, HTTP caching isn't required, it's only advisory; many people
> lament the fact that you can't force a cache to keep something, but
> arguably caching would never have taken off if it had been required.

IMHO this is the wrong comparison. We're modeling a sender-side
property, for example the value of "Cache" HTTP header. Our approach is
like saying: Here's how the Cache HTTP header is sent with a GET
response, and the sender node (the one that responds to GET) has the
property "Cache-value" which is a hint on what the HTTP layer of the
node might put in the header when sending the response.

What I'm proposing is not that the application provide the final value
of the property, but that when the optimization actually occurs, the
property value is final and binding. This retains all the flexibility,
forgivingness and potential efficiency of implementations.

> > I see four separate deliverables that I think should be the next product
> > of the XMLP WG:
> >
> > 1) the abstract feature
> > 2) the HTTP binding (including the inclusion specification which need
> > not be standalone)
> 
> It sounds to me like people want to be able to use inclusion in other
> underlying transports, which argues for making it separable.
> 
> > 3) the MediaType stuff (carrying generally binary data in XML infoset)
> 
> FWIW, I'd characterise this as leveraging the internet media type system
> within XML.
> 
> 
> > 4) the Representation stuff (carrying representations of web resources
> > in SOAP messages)
> 
> This is especially interesting. I don't think it's necessarily
> SOAP-specific...

Same as number 3. 8-)

Best regards,

                   Jacek Kopecky

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

Received on Wednesday, 16 July 2003 12:03:10 UTC