On 3/21/07, Luigi Lauro <[EMAIL PROTECTED]> wrote:
As I previously announced, I've started working on this RFE ( https://
issues.apache.org/jira/browse/DERBY-2469 ), implementing a
WritableStorageFactory (along with StorageFile of course) around the
Java Web Start JNLP PersistenceService API.
</snip a lot of great comments about the approach>
I've noticed there is an abstract InputStreamFile class which
implements read-only methods around an inputstream, is this useful
for me you think? I notice it also depends on the BaseStorageFactory
class as well: do you think it's better if I start off from these 2
base classes, given my needs?
I know next to nothing about JNLP, but given the URL based nature of
JNLP resources, I'm wondering if the current URLFile and
URLStorageFactory could be adapted / extended to meet your needs?
Also: is there a derby test-suite available for full
WritableStorageFactory/StorageFile/StorageRandomAccessFile coverage
tests?
While there are tests that cover this area, if you are looking for
tests that can be quickly and easily adapted to cover your new JNLP
storage service, then I think the answer to this is currently no. An
effort is underway to convert Derby's tests from an old canon-based
style to an assert style, though, and help in the store area would be
greatly appreciated. See:
http://wiki.apache.org/db-derby/DerbyDev
http://wiki.apache.org/db-derby/DerbyTesting
http://wiki.apache.org/db-derby/KillDerbyTestHarness
Also #2: someone knows if there's a way for testing JNLP APIs outside
of a Java Web Start environment?
There is probably a way to load the PersistanceService outside of an
explicit Java Web Start environment. Those more familiar with JNLP
would probably be more help here.
*** What have I done?
Very little, just this long brainstorming regarding how things are
and how to proceed, and a starting JNLPStorageFactory with some
methods implemented in as a start and to make me understand what
needs to be done.
Brainstorming is great, but code is better! Please feel free to attach
anything you have developed, even half-baked, to the JIRA issue you
opened for this. Patches don't have to be perfect, since they provide
a basis for further discussion.
*** How can you help?
Read all this (woohoo! This is a feat!), and answer here with your
thoughts/suggestions/critics/ideas/jokes/whatever. Also, provides
code if you feel like it, or get in touch with me (mail) if you wanna
get actively involved in the coding I'm done.
Thanks for the great writeup! I hope a lot of these implementation
details can be captured in the comments and javadoc of the code.
Keeping these sorts of details in the code makes it easier for those
working with the code in the future to modify and enhance it.
I would suggest attaching any work you've already done to the JIRA
issue you've opened. This is the easiest way to allow others in the
Derby community to collaborate on the code. Also, keeping the
discussions around the feature on the derby-dev mailing list or in
JIRA keeps everyone in the development community informed on its
progress.
Feel free to post any questions or comments you have to this list, and
thanks for jumping in and offering something useful to the Derby
community!
andrew
