Re: update to Issue #82

Mark,

I agree with you.

Mark Jones wrote:
>
> [...] 
> 
> The balance to simplicity is efficiency.  It looks like we have
> a couple of (competing?) considerations.
> 
> 1) You'd like memory-limited devices to be able to generate various
>    blocks without having to do buffering.  Actually, in the general
>    case, you would like all of the handlers on the sender that
>    contribute blocks to do so without undue worry about buffering
>    issues.  If messages could be incrementally constructed (and transported)
>    without regard for the order in which independent handlers inserted
>    blocks this would be a big win.
> 
> 2) You'd like intermediaries to be able to find, parse and process
>    blocks intended for them as efficiently as possible. (And to
>    avoid buffering, etc. insofar as possible.)
> 
> Syntactic simplicity is further down my list.  Eliminating the
> header/body distinction does have syntactic simplicity on its side and
> it happens to resonate with efficiency (1), but not necessarily
> efficiency (2).  Maybe there is another syntax that works even better
> than either strict header/body or mixed header/body blocks that
> facilitates both efficiency (1) and (2).  In the design phase, we should
> think about the issue and see what we can come up with.
> 
> [...] 

I think you pinpointed the problem raised in issue #82.

Removing the header/body distinction allows a more efficient handling of
(1), while it has mostly no effect on (2).

The rest of your message make me think that whether or not we keep the
header/body distinction, we already have a good solution in regards of
(2) and that there may not be truly more efficient solution aside from
undergoing a radical change in our design.
I just have a feeling that, without header/body distinction, some XMLP
applications could improve their efficiency (2) by a smart ordering of
the blocks.

Hervé.

Received on Thursday, 26 April 2001 04:42:46 UTC