Much thanks on that last paragraph. I wouldn't have gathered that from the presentation, but it now makes me smile just a little more now :)
On Tue, Jun 9, 2009 at 10:11 AM, Mike Schrag<[email protected]> wrote: >> 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/jmlittle%40gmail.com > > This email sent to [email protected] > _______________________________________________ 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]
