On Tue, Jun 9, 2009 at 11:40 AM, Joe Little<[email protected]> wrote: > 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 :) >
sorry, this is in regards to using these technologies in basic web pages just as much as a full RIA > 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]
