Re:
> # 27.  Allow tracking files to be associated with a database:
> # 28.  Tool "memory area" file(s) associated with a database:
>
> .. Although:  As I read through them again now in the context
> of the current discussion, I wonder if items # 27 & # 28 could
> be productively combined into one enhancement.. Yeah, I think
> so;  just different variations of the same basic idea...  And if the

They're different.  #27 allows people/tools to say "hey, file FOO
should be stored/purged when this database is stored/purged".  You
don't necessarily know what the file FOO is used for...but that doesn't
matter.

#28 allows tools to say "hey, let's remember that I was here, and that
I noticed xxxx about this database".  Then, at a later time, the tool
could say "hey, you've asked to do yyyy, but I remember xxx which
somehow is related/important/interesting".  This has little to do with
files ... that's why I originally suggested them as two separate
enhancements.  As it turns out, it would be very easy to add both
to IMAGE nowdays, leveraging off of some work done for the jumbo
dataset project.

> "Allow tracking files and Tool "memory area" data files to be
> associated with a database in the root file".
>
> COMMENTs (especially from Stan, since believe these were
> both his ideas) ??

> Basically we appear to have two schools of thought WRT BLOBs:
> (1)   BLOBs should *not* be stored directly in IMAGE;  store
> (2)   Users should be able to store reasonably small BLOBs
> (Java objects, digitized signatures, maybe things like small MS

I suggested to the SIEC that I'm in favor of *both* approaches.
(When given a choice between A and B, I like to choose C :)

The short form of what I suggested is:

    new data type:  B1    --> small BLOB (<= 64KB)
                              stored within an IMAGE dataset, covered
                              by XM.

    new data type:  B2    --> big blob (no limit, generally bigger
                              than 64KB, but not necessarily)
                              data stored outside IMAGE (perhaps one file
                              per BLOB), with pointer/name/size info stored
                              in IMAGE.  Data not covered by XM.

> on this one).  One member of the SIEC threw out 64K as an
> off-the-top stab at defining the limits of a "small" BLOB.  His

Me...that was me...  (sheesh, it's too late tonight, Xena's over, and
I ought to be going to sleep instead of reading email)

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html