No, I thought it wasn't really clear either - I thought it was local
storage at first too, but it's not - It's a Javascript CoreData
implementation accessing an ERXRest backend on the server. If I'm
wrong someone please correct me.
Also, you would have to rewrite EOEditingContext and related classes
in Javascript, which is a fairly large task.
But I thought that was part of what Gianduia did and what made it so
much cooler than last years rich-client-of-the-moment Sprout Core.
Yes, but CoreData != EOF. They are similar, but not the same. I'm
not sure why they chose CoreData instead of EOF; maybe since
CoreData was newly designed it is actually better than EOF; I don't
know, I haven't used it.
Okay. I must have misunderstood that part of the presentation. I
thought that CoreData was there just for local persistence of things
and that it _also_ had EOF-like ECs also.
Not sure what part of EOF you feel like you would be missing, but it
should have most of the parts that matter. It has the equivalent of
an EditingContext via NSManagedObjectContext. So you have in-memory
change tracking pretty similar to what you would in EOF.
Additionally, you have multiple persistent store implementations.
Right now, the implementations are mostly pragmatic for the particular
use cases of Gianduia -- so actually there is NOT an HTML5 one
implemented yet, but this is almost certainly an impl that would be
desirable to have.
As far as why Gianduia doesn't use EOF, I would GUESS that it's
because the js side is Cocoa and CD was the newer kid on the block, so
it just made sense. Additionally, CD is sort of stripped down, and
many of the things they removed are not that big of a loss for the use
cases one would use this kind of persistence layer with.
There are obviously differences between EOF and CoreData, and Gianduia
does share those differences. For instance, there is not a
centralized snapshot store in CoreData -- snapshots are stored in the
NSMOC, so you don't get update notifications across NSMOC. Whether
this will be a problem or not with the kinds of apps people will want
to make with GIanduia remains to be seen .. It's unclear what the best
practices of these kinds of apps will be. That said, Gianduia is
"highly inspired" by Cocoa, but not "required to be identical" to it,
so if it makes sense to deviate, that's certainly on the table. I
think Benoit has done a great job at adapting the philosophy of Cocoa
to a Javascript framework. He's what I would consider a Javascript
expert, and he exploits the capabilities of the language where it's
appropriate, and the result so far has been a really good balance.
For the question about EODistribution, it's important to note that
Gianduia doesn't just talk to WO. It can talk to anything. I'm
assuming when the persistence layer was originally written, it was
desirably to not require a very complicated server to communicate
with. As it stands, you can talk to a Rails server if you want -- it
doesn't have to fully implement all the semantics of EOF to do what it
needs to do. That said, when the richer persistence features become
available (like bulk faulting in a single request), this WILL require
a more complicated server implementation, so it remains to be seen
exactly what will be required on a server to get the bare minimum of
capabilities. However, as it stands, you don't have to implement a
server side of much at all, because you can manually load snapshots
into your NSMOC from data you fetch manually ... In my demo, I was
actually doing that in several places. This gives you a lot of freedom
of not necessarily being locked into exactly the semantics of either
EOF OR CD.
Additionally, I find the modeling controls for JavaClient to be pretty
lacking -- in particular with respect to ACL controls on JavaClient
properties. It feels like that was something they stuck into EOF
without really solving the problem well. In many ways, what these
frameworks allow is truly partial faulting -- I can selectively return
a subset of an EO/MO that specifically provides what the client needs
with a minimal footprint. If you look at something like MobileMe, You
can imagine that the model on the backend for, for instance, a mail
folder might be extensive, but depending on what the client is doing
at different times, you may only what specific subsets of that
entity. At first, you may literally only care about title (and maybe
"unread message count"). When I drill into it, I may want more info
about the folder like my size restrictions, and various properties on
the folder. JavaClient and EO don't support partial faulting of an
object right now, and it's something that I've found to be really nice
when trying to optimize bandwidth for remote clients.
My other goal with the ERRest framework (or ERXRest .. i have no idea
what it really is now, since the framework is ERRest, but the class
names are ERX because they were originally in ERX. sigh) is to provide
a common set of API's that you can implement and end up with a viable
generalized JSON/PList/Whatever service API (for cocoa, rails,
whatever clients) AS WELL as a viable API for use with a persistence
engine like Gianduia. There are some hard problems to be solved with
this still (the bulk request/fault routing stuff, for instance, is a
lot of theory that hasn't been tested), but as I mentioned in my talk,
my experience with trying to make the framework too automatic and too
magic was sort of a failure, and the direction the new API's are going
make a lot more sense, and that is a direction that is definitely not
really like EODistribution.
So to me, the idea of EODistribution is good, but as it's currently
implemented, I think it makes it hard to achieve the goals I was
hoping to meet with the framework.
That said, Gianduia is not out yet, and there are lots of
opportunities to make changes to things. What we showed is really a
technology preview. It's a pretty mature technology preview, but a
preview nonetheless.
The other thing I sort of said in a recent tweet is that Gianduia is
not necessarily about building rich javascript applications. You can
use it to build what people currently think of when you say "rich
javascript client" (like Cappuccino), but just as importantly, you can
build a completely normal and traditional web page that just has some
cool rich interactions on it. This is a key difference between
Cappuccino and Gianduia. Cappuccino is specifically designed to make
a desktop app on the web. Gianduia supports this, but it is more
about unlocking the power of these technologies on the client and
applying some fairly proven approaches (wo templating, kvo/kvb, the
basic design of the cocoa apis, etc) to make them really much easier
to exploit without giving up what makes web technologies cool in the
first place. That there's a natural synergy between WO development and
Gianduia development is just icing on that cake.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
