Thanks for your interest in this. Here is my perspective on this topic.
1. What we have already works on Android. At least once in your
email you described "when backporting to Android" and I'd rather not
look at this way. Instead I would propose we break this into several
smaller taks. Each of which could be accomplished without breaking
what we already have.
2. I have no opinion on H2. What I would like to see is an
abstraction in TouchDB for the persistence layer. Then have a module
which maps the existing Android persistence to that abstraction. Then
have a JDBC implementation (possibly somewhat abstract) which allows
for specific database modules to plug-in where necessary. I think
this is the biggest difference from what you proposed below. I
wouldn't try to re-use much code between what we have now for Android
persistance and the new JDBC persistance. I would propose we have a
persistance API (interface), with multiple implementations. Obviously
the initial JDBC implementation would borrow much of its logic from
the Android one, but to me it seems like theres enough differences to
keep them separate.
That being said here is how I would break down the tasks.
1. Convert all logging calls to sl4j. This can probably be done with
a clever regular expression search and replace.
2. Reevaluate concurrency implementation in TouchDB. If it can be
written once in a way that works everywhere, without sacrificing
anything that would be my first choice. If not, introduce some
abstraction so that we can plug-in android/non-android
implementations. I need to do more research here before we make any
changes. I already think the way I did some of it in TouchDB wasn't
right to begin with (too many handler threads)
3. Introduce a persistence abstraction to TouchDB. This will take
some time to iron out. It's basically most of TDDatabase and part of
TDView, but there is non-persistence logic in these classes to that
must be broken out. The output of this step should be an interface.
We'll probably also need to introduce some TDServer factory that
instantiates the right implementation for you.
4. Once we have #3, create an Android implementation of #3 and rewire
things to go through this. This should be done in a separate module.
When this step is complete users would need a touchdb.jar and a
touchdb-android.jar.
5. Introduce a JDBC implementation (again possibly abstract). This
would allow non-android users to use touchdb.jar and touchdb-jdbc.jar
6. Introduce concrete implementations for other databases. Again, it
might be touchdb.jar, touchdb-jdbc.jar and touchdb-h2.jar
We have a reasonable number of unit tests right now, and I think we
take an approach like this we can get to where you want to go. If I
get a monster patch that mixes all these things together I may never
find the time to properly review it. And if I get patches that break
things for Android I'm not going to push them through.
Do we have anyone other people in the group interested in these changes?
marty