The design ideas posted to the web look pretty good, and an obvious
extension to ideas already in use (drawing from current practice in
both cdevData and GDD). Below are a few detailed suggestions.
> The user will be able to assign a special destructor to a dataEntry
> object. This destructor will be called to delete the data that is
> stored by the object when the reference count is decreased to 0.
Instead of registering functions, callers should register objects
which implement specified methods. This will make the Java
implementation easier, and is better OO design. As a general
practice, I would like us not to implement any more C++ API's which
pass functions as arguments.
> A companion method to the stream functions will be provided that
> allows the user to discover the length of the binary stream that will
> be produced by a dataEntry object.
If this is not the XDR format used by CLIP, I would strongly
recommend looking into the format used by Java to send objects, so
that Java applets can more easily communicate with C++ clients.
(Although I suppose when Java gets accelerated, we might write
both the client and server in Java, and not use whatever network
encoding we define here for Java programs.)
> Access to dynamically allocated dataEntry objects may be accomplished
> through the use of small hash tables within each container.
Hashing is only efficient if the number of entries exceeds 15. Do we
believe this to be the expected case? Indexing a predefined order is
the fastest, but linear search is the fastest way to access an unordered
set for small set sizes. Dynamically switch?
Chip