At 06:48 AM 12/2/2004, Olivier Mascia wrote:

>OM> For what the C-API is concerned with, what are the differences between
>OM> "streamed" blobs and blobs ?

Blobs come in two forms. The original, designed when we were at
DEC are called segmented blobs. Most of DECs file systems were
record oriented, including text files. The concept of null
terminated strings was known, but was isolated to one PDP-11
operating system (RSTS/E) and a product called Dibol. The use
of null terminated strings in Unix was widely regarded as a
sign of the system's backwardness.

So, coming from that culture, the natural way to handle large
objects was in segments. Typically, a text file was stored one
line per segment - there are remnants of that in qli which will
tend to put a carriage return at the end of a segment. And yes,
segmented blobs are perfectly happy having each segment a
a different length. A segmented blob consists of a two byte
segment length followed by that number of bytes of data,
followed by the next segment length and data, etc.

After about five years of working on systems where the native
representation of a string was null terminated, Jim got comfortable
with that notion, and introduced the concept of a stream blob. We
added some frosting to make it look like C string handling - putb,
getb, and some positioning stuff. Internally, stream blobs are
just data bytes.

When Borland took over, they largely ignored blobs and completely
ignored stream blobs. The devel list is mulling over some problems
with stream blobs - the positioning code, for example, uses 32 bit
offsets, positive and negative, so you can't perform random access
on any part of a stream blob more than 2Gb from the front.

Stream blobs are a more natural representation of data for C
programs. They haven't been used in a long time and they're
going to give us a bit of problem until we shake out the moths
and patch the damage.

Regards,


Ann