Issue 1522:  OBV "chunking" (obv-rtf)
Source:  (, )
Nature:  Revision
Severity: 
Summary: Summary: The OBV spec adds the notion of "chunking" because it claims that "it is
 anticipated that value types may be rather large, particularly when a graph
 is being transmitted. Hence the encoding supports the breaking up of the
 serialization into an arbitrary number of "chunks" in order to facilitate
 incremental processing." (orbos/98-01-18, page 5-55)
 
 This "feature" should be removed from the spec, since it is the job of the
 underlying transport to handle this issue. GIOP already provides
 fragmentation, allowing transports to handle large parameters efficiently
 -- why should we build yet another fragmentation solution on top of it?
 

Resolution: 
Revised Text: 
Actions taken:
June 11, 1998: received issue
July 30, 1998: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <vinoski@iona.com>
X-Sender: vinoski@mail.boston.iona.ie
Date: Thu, 11 Jun 1998 19:07:50 -0400
To: issues@omg.org, obv-rtf@omg.org
From: Steve Vinoski <vinoski@iona.com>
Subject: OBV "chunking"

The OBV spec adds the notion of "chunking" because it claims that "it
is
anticipated that value types may be rather large, particularly when a
graph
is being transmitted. Hence the encoding supports the breaking up of
the
serialization into an arbitrary number of "chunks" in order to
facilitate
incremental processing." (orbos/98-01-18, page 5-55)

This "feature" should be removed from the spec, since it is the job of
the
underlying transport to handle this issue. GIOP already provides
fragmentation, allowing transports to handle large parameters
efficiently
-- why should we build yet another fragmentation solution on top of
it?

--steve

Return-Path: <goldberg@inprise.com>
Date: Thu, 11 Jun 1998 21:57:17 -0700
From: Jon Goldberg <goldberg@inprise.com>
To: Steve Vinoski <vinoski@iona.com>
CC: issues@omg.org, obv-rtf@omg.org
Subject: Re: OBV "chunking"
References: <s58008dc.061@corp.inprise.com>

Steve Vinoski wrote:
> 
> The OBV spec adds the notion of "chunking" because it claims that
> "it is
> anticipated that value types may be rather large, particularly when
> a graph
> is being transmitted. Hence the encoding supports the breaking up of
> the
> serialization into an arbitrary number of "chunks" in order to
> facilitate
> incremental processing." (orbos/98-01-18, page 5-55)
> 
> This "feature" should be removed from the spec, since it is the job
> of the
> underlying transport to handle this issue. GIOP already provides
> fragmentation, allowing transports to handle large parameters
> efficiently
> -- why should we build yet another fragmentation solution on top of
> it?

I agree that the stated reason for chunking should really
be accomidated by the underlying protocol via fragmentation.

Unfortunately, there is another reason for chunking that fragmentation
cannot handle:  truncation.  Every value *must* indicate where it
ends so that truncated values can be skipped apropriately.  Chunking
and end tags are the solution to this problem.

take care,
 Jon

Return-Path: <vinoski@iona.com>
X-Sender: vinoski@mail.boston.iona.ie
Date: Sat, 13 Jun 1998 15:20:47 -0400
To: nash@hursley.ibm.com
From: Steve Vinoski <vinoski@iona.com>
Subject: Re: OBV "chunking"
Cc: obv-rtf@omg.org, issues@omg.org
References: <s58008dc.061@corp.inprise.com>
 <3580B52D.3C2C8BB4@inprise.com>

At 02:11 PM 6/12/98 +0100, Simon Nash wrote:
>Chunking and fragmentation complement one another.  It is because
>of fragmentation that we need chunking.

The real issue is that the spec says absolutely nothing about what you
and
Jon have pointed out. If chunking is needed, the spec should explain
why.
The only rationale it currently supplies for the chunking is that
values
can be very long, which is neither helpful nor informative.

I suggest that the explanations you and Jon have provided in this
discussion should be combined to fix the text in the spec that
currently
explains (or rather, fails to explain) what chunking is. Jon told me
that
the two of you have been working on cleaning up that particular
section of
the spec, and so I look forward to seeing your revision proposal.

thanks,
--steve