Re: GOAD ID size restriction?

[Nat Friedman <nat nat org>]

Elliot Lee <sopwith@redhat.com> wrote:
> On Thu, 22 Jul 1999, Miguel de Icaza wrote:
> 
> > > Methinks you need to have some saner client-side interface that knows
> > > about buffering etc. :-)
> > 
> > Perhaps, but I do not feel very confortable with having a library call
> > moving my file pointer on the GNOME stream.
> 
> I don't understand what the problem is here. You use a set of
> gnome-stream-client.h routines that wrap all the IDL:GNOME/Stream:1.0
> operations but add buffering, and all is well in the land.
> 
> > > I'm not against a maximum size, but it will be hard to find the perfect
> > > one that gives enough room for expansion without wasting space.
> > 
> > 64 bytes strikes me as a nice default.

Wait a minute, I'm not so confident about this idea.

If we're not going to use UUIDs which are guaranteed-unique within 64
bytes, then limiting the GOAD ID we store on disk to 64 bytes is a
serious flaw.  There are only two ways to solve this problem, as I see
it:

	1. Use UUIDs with guaranteed uniqueness within the first N
	   bytes and store those N bytes in the compound document.

	2. Do the client-side buffering as Elliot suggested.

Just saying "GOAD IDs are 64 bytes" is a terrible kludge to apply to
this problem.  I don't see what's wrong with solution #2, as Elliot
proposed, but then again, I don't see what's wrong with #1, either :-)

Best,
Nat