I just wrote:

> But if you code your blobs to be some fixed length (e.g., X1024), you're
>  cooking with high-octane petroleum distillate at full flame -- and you can
>  implement blobs in your IMAGE database right now. Precisely because IMAGE
>  does no data checking of any sort, you can fill your X1024 field with any
>  pattern of 1's and 0's that you wish. What those 1's and 0's mean is wholly
>  between you and your application codings. They, like every other field
value
>  in IMAGE, have no meaning to IMAGE itself.

In my editings of my note that I performed before I posted it to the list, a
few sentences unfortunately got dropped. My apologies for the waste of
bandwidth, but I feel they are important enough that I'll repeat them here:

"Precisely because IMAGE does no data checking of any sort, you can fill your
X1024 field with any pattern of 1's and 0's that you wish. What those 1's and
0's mean is wholly between you and your application codings. [The bits can be
a pointer to an HFS file name, as Michael suggests, or even to an MPE
namespace file name, or alternatively the 1's and 0's can actually be the
blob itself.] They, like every other field value in IMAGE, have no meaning to
IMAGE itself.

"Further, if [you choose to store the blob directly in your IMAGE database]
and your blob is greater than 1024 bytes, you can string together any number
of records containing these X1024 datafields as a simple sequence of
records..."

Wirt