Re: update to Issue #82

A related question:

Is a general mechanism for grouping blocks is useful?

For example, in the digitial signing note,
the dsig block contains a reference to the id of the block
to be signed.  In the example it is the "body".  Without it,
a list of individual tags might have to be included.

So maybe one way of making it easier to format such
a document would be to allow generalized
grouping with user specified names.  Such a group
could be targetted, referred to in a reference, etc.

Herve Ruellan wrote:

> 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 14:25:26 UTC