• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Rich Clients and WO
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rich Clients and WO


  • Subject: Re: Rich Clients and WO
  • From: Stamenkovic Florijan <email@hidden>
  • Date: Wed, 10 Jun 2009 10:57:11 -0400

A few things here need addressing.

On Jun 09, 2009, at 11:08, John Huss wrote:

I believe JavaClient uses the standard Java serialization, which is a binary format. Generating the format in Javascript is probably not feasible; if it was I'm sure the GWT folks would have used it, but they didn't.

I would not be sure of this. I know that it uses NSCoding stuff, ported to Java, to do RMI transfers, and in that sense it *might* be reasonable to assume it also uses NSCoding for archiving content on other client-server ops. As for how NSCoding is implemented below the surface, I can't say, but I don't think it relies on Java's serialization, as it's quite picky about what it accepts or not (it does not accept many Java classes that are Serializeable).


But yes, either way it is binary data.

Also, JavaClient's serialization is HEAVY since the whole EC is transferred (I think) with each request to the server,which kind of makes sense actually, but is possibly an expensive operation.

It does not make sense, and does not happen. There is a load of client / server communication, but it is quite optimized (not to say there isn't room for improvements). The client side contexts perform more or less as child editing context of their server side counterparts, with some additional layers in between. Meaning: data is fetched / transferred on demand, and only the data that is asked for / required is transferred. Resulting in a wide scale of response sizes.


The transfer of an entire editing context object *never* happens. Appropriate ECs are instantiated on the client and the server and they communicate EO data over the pipe. There is other data being transferred as well (EOClassDescriptions, custom RMI calls), but these generally represent a less frequent, and mostly less expensive traffic.

Also, you would have to rewrite EOEditingContext and related classes in Javascript, which is a fairly large task.

Yep. Also I don't really know if it's possible. I don't do JavaScript, but from what I understand it is by no means strong enough create such complex functionality in.


F
_______________________________________________
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


References: 
 >Rich Clients and WO (From: David Avendasora <email@hidden>)
 >Re: Rich Clients and WO (From: John Huss <email@hidden>)

  • Prev by Date: Re: I need some help with this Ajax Dom stuff
  • Next by Date: nsruleeditor (or nsprediateeditor) WebObjects equivalent
  • Previous by thread: Re: Rich Clients and WO
  • Next by thread: Hudson gives awt.headless error
  • Index(es):
    • Date
    • Thread