Re: Proposal for multi-reference support in MTOM

On 17 Nov 2003, at 21:07, [email protected] wrote:
>
>> To allay your first concern, I'd be open to
>> recommending that the binding check for differences
>> during serialization. Computing a low cost hash during
>> serialization wouldn't add much overhead I suspect.
>

<snip/>

> I'm not saying this
> is necessarily impractical, I'm saying that it's far
> from obvious that the impacts are negligble, especially
> given that part of the reason for MTOM is to deal
> efficiently with very large amounts of data.
>
> Also: isn't the point of using the IDs exactly so that
> you don't have to check the contents?  Whatever the
> other merits of using the same MIME part for two or
> more bits of identical content, if you're going to
> check the content anyway, wouldn't it make some sense
> to skip the IDs?
>
You were concerned about losing info so I offered the possibility of 
checking for equality. I can imagine better ways of ensuring equality, 
e.g. only a single instance of the multi-referenced data in memory and 
multiple pointers to that with a copy-on-write scheme but then you're 
getting into implementation details. Recommending an equality check in 
the abstract would not prevent such optimizations.

>> I agree that UUID/GUIDs may not be usable in every
>> environment but note that RFC 2111 requires that "the
>> Content-ID of a MIME body part is required to be
>> globally unique" so the problem exists independent of
>> MTOM usage. Simply reusing the content-id of the part
>> as the attribute value would suffice for MTOM
>> multi-reference support.
>
> If I understand what you're saying, that would put
> the CID URI in both the hint attribute and also
> in the xbinc:include?  Seems sort of strange.
> Maybe I'm misunderstanding.
>
No, you're right - in my example I had a comment noting that depending 
on the semantics of the hint attribute the xbinc:Include/@href might be 
redundant.

> Thank you for your patience with my concerns!
>
No problem, I think its important that we explore all the implications 
of each choice.

Marc.

--
Marc Hadley <[email protected]>
Web Technologies and Standards, Sun Microsystems.