Re: Rich Clients and WO
Re: Rich Clients and WO
- Subject: Re: Rich Clients and WO
- From: Joe Little <email@hidden>
- Date: Tue, 9 Jun 2009 11:40:37 -0700
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@hidden> 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@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