[Waba-spec] The registry, etc.

[Sean L. <se...@cs...>]

Here are my initial thoughts on the final Registry description.

1. There is no reason why you shouldn't be able to skip negative bytes.  
If you back up to position X, and then start writing, the Registry 
should assume that everything after X is automatically deleted.

2. What happens if you delete the registry while it's open?  Can you 
continue to write?  Would that recreate the registry (I assume not)?  Or 
do you have to call getRegistry() again?

3. There should be a function indicating the maximum feasible number of 
bytes that the registry can hold.

4. I presume that the registry does not take locking into consideration: 
if you have multiple instances of your application open, I presume the 
result is undefined?  Which is fine, just as long as we state this.

Now as to some other stuff.  Olivier had written:

> - take the Ewe's Datastore package and insert it in the extension API.

By my read, Datastore requires a *lot* of underlying modification; 
further I think it is inappropriate for environments which do not file 
storage.  Am I misreading the description?

If Datastore can sit on top of existing stream protocols with little or 
no underlying VM changes, then I think we might consider it.  But if it 
requires VM modification, we should talk about it some more: I don't 
like the idea of changing the VM semantics to support a nonstandard 
package.  That's a recipe for spaghetti code.  So I want to discuss this 
further first.


> - postpone the java.util.Map (and the associated class) to the next
>   release of the specifications.

In truth, I don't think we should implement Map at all.  The CLDC 
doesn't.  It's too heavyweight for our purposes.


> - postpone the serialization also to a future release of the API.

Serialization is a LARGE addition to the VM, both in terms of VM support 
underneath, and in terms of supporting Java classes.  That's why, for 
example, that the CLDC doesn't support it.  I think we should think very 
hard whether or not the advantages of the feature (which I use heavily 
in "real" Java programs) outweigh its significant disadvantages in terms 
of majorly bloating the system.


> - move the Catalog class to the Palm platform specific branch. This mean
>   it's available for the Palm implementation, but not necessary for
>   others.
> <<
>
>    Disagree. Catalog must be implemented in all platforms. Otherwise, no
> Palm programs will able to run other platforms without being modified.

But that's why they're *Palm* programs!  If you want to run on other 
platforms without being modified, use the Registry class and/or a 
Database class replacement of some sort.


> - take http://waba.sourceforge.net/javadoc/waba/io/CatalogSeanLuke.html
>   for the base of the discussion when the topic "Catalog class" will
>   come.
> <<
>
>  Does this make sense in other platforms too?
>
>   /** Retrieves the attributes of the current record. Use the 
> REC_ATTR_xxx
> masks to set/retrieve its states. @returns 0 if db dont exists @since 
> 2.0 */
>    public byte getRecordAttributes()
>    {
>       return NativeMethods.nm.catalogGetRecordAttributes(this);
>    }

Record attributes are a Palm thing, ar they not?  What kind of 
general-purpose "attributes" are you thinking of?  I can still be 
convinced.


> To limit the discussions, I suggest to agree with complete package, and
> not to split them. I suggest to take all but the Throwable. This mean,
> WRAPPER, UTILITY, SYSTEM and MODIFIED. I know Sean say the last one to
> take is SYSTEM, but I think if we take them later, the classes allready
> in Waba continue to diverge, and it will be more difficult in the future
> to change them.

Yeah, that's doable, though I might need some help on implementing the 
Class class.  The throwable classes may be easily removed, but only by 
commenting out all the "throw" statements in the other classes; 
otherwise they will get compiled in with the other class files when you 
make your app.  That's fine to do this, though we should keep "thrown" 
versions of the classes around that are compatible for the future 
situations when we do (?) get exception handling.

BTW, I don't recall if the Vector class has backward-compatible 
functions for the old waba.util.Vector class or not, it's easily enough 
added in.

Sean