[oscar-devel] Input on Oscar storage abstraction

[Richard S. H. <he...@un...>]

I have been working to get bundle update working for the next release of 
Oscar.  Along the way, I decided to abstract the way Oscar uses 
persistent storage.

It was my thinking that instead of tying Oscar to File objects, that I 
would create a simple set of interfaces that did not depend on File 
objects and instead used InputStream/OutputStream objects.  The 
reasoning behind this is simple, the File object assumes there is a file 
system underneath Oscar and I thought that this might not always be the 
case.  Therefore, by abstracting Oscar's storage mechanism, it would be 
easy to create different storage implementations, such as an 
"all-in-memory" one or one that used a database (perhaps for roaming 
profiles).

So, I created these interfaces:

    * StorageSystem - provides access to the storage system; Oscar
      requires one for operation, a default file system implementation
      is provided.
    * StorageNode - abstract interface for a storage node.
    * StorageDirectory - a hierarchical grouping mechanism for the
      storage system.
    * StorageFile - used to get an InputStream/OutputStream for a
      storage system file.

In all, these interfaces are very simple (i.e., they only have 2 to 4 
methods each); the point is to keep them simple so they are easy to 
implement.

Oscar has been modified to use this approach and everything is working 
as before, so I thought that this was a pretty good design improvement.

Well, there is a catch.  In the previous version of Oscar I was using 
the JarFile class to read from the bundle JAR files, but the JarFile 
class cannot be initialized using an InputStream only a File (most 
likely because it needs a random access file).  As a result, I modified 
Oscar to load classes using a JarInputStream to read from the bundle 
JAR.  This modification led to a noticable performance loss when loading 
classes because I must sequentially search the JAR file for each 
resource.  In general, this is most noticable on start-up, but once 
classes are loaded everything operates normally.

I tried to look at the JarFile code to see if I could figure out how to 
read the Jar/Zip index to speed up my searches, but those portions of 
JarFile are implemented in native methods.  Obviously, I could look 
elsewhere for this information, but I am not sure if it is worth it.

Does anyone have any thoughts on improving performance or a better 
approach for reading JAR file entries from an input stream?  I do think 
the re-design is nicer since it frees Oscar from requiring a file 
system, but perhaps the performance loss isn't worth the price.

Any thoughts?

-> richard