Re: JavaClient offline storage / replication
Re: JavaClient offline storage / replication
- Subject: Re: JavaClient offline storage / replication
- From: David Avendasora <email@hidden>
- Date: Wed, 15 Apr 2009 12:25:46 -0400
On Apr 15, 2009, at 11:51 AM, Stamenkovic Florijan wrote:
On Apr 15, 2009, at 11:24, John Huss wrote:
We're considering using JavaClient for some new projects and one of
the big features we want is the ability to run offline by caching
database from the server's DB and storing any modifications locally
until the server is online again. How would you approach this? Is
it possible to use the same EOModel and use EOF on the client to
save the data locally?
Your way: no. You are not allowed to do this. You can only
distribute the client-side libs in your client app, and those do not
contain the functionality to connect to whichever data-source
(EOAccess).
I'm not entirely sure this is true anymore. If you can deploy a
standard WO app to any platform for free, why can't a "client" machine
run the same stuff as a "server"? I know that when it cost money for a
deployment license, they specifically said you could send the client-
side apps to a client for free. But now that the whole thing is
free... why not?
Here are some thoughts that I had on this subject in the past...
Basically two ideas occurred to me for handling this.
1. Serializing an EOEditingContext. EOEC implements Serializable.
And if you think about it, it might be! However, in a practical JC
scenario this does not really do you any good. An EC will want a
parent object store, and without a connection to the WO server, you
can't give it one. And even if you somehow manage to hack this, as
soon as a fault gets fired, and you don't have a connection to your
data source, you're screwed.
2. Now, this is a pretty big idea, on my to-do-in-the-coming-5-years
list. It comes down to implementing:
a) Local persistence support for JBND
b) A further elaboration of non-persistence-specific relational
concepts for JBND
c) JBND code that focused on migrating data from one persistence
system to another
d) An "AppKit" architecture that is JBND based and focuses on
writing client apps that are capable of dealing with multiple
persistence sources, and to switch connections between them
dynamically, or at least have multiple connections in parallel
This would solve your problem, as it would allow you to migrate EOF
data from WOJC to local persistence data, and back again. In short,
it is the only solution I could think of to the same problem you
have, though admittedly it addresses a bit more then just those
issues. The only problem is: while this *might* be possible, I bet
that to bring it to a functional, usable implementation, it would
take (me, alone) at least half a year of focused work. Which I will
not be doing :) However, if you are into this, and feel up to the
(rather large) challenge, I'd be happy to support the effort.
Besides that, well, WOJC was not meant to do this. Unfortunately.
However, if anyone has an idea on twisting it's arm to make it do
it, I'm all ears.
HTH,
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden