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:41:50 -0700
On Tue, Jun 9, 2009 at 11:40 AM, Joe Little<email@hidden> 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@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