quoth Michael Pemberton:
>> The problem with posting large amounts of data remains. 3k is not really
alot
>> of room.
I usually find it to be quite a bit of room for sending data to the server.
There is a much larger limit for receiving data from the server (not sure
what it is exactly - the size of a textarea - haven't run into it). With IE
and Mozilla, I can make JSRS work with POST to overcome the client-to-server
limit, but it doesn't work on Netscape 4.x Layers, so I've left it out.
Many if not most RS designs should function well within the limitations.
>> Also, the problem of syncronization remains. with the java version, the
method
>> does not return until after the data is downloaded. The js version
requires
>> looping and such to stop it from continuing before the data is loaded.
I find it's pretty simple to just call the remote routine and then continue
the task in the callback - there are variable scoping issues but otherwise
it looks almost just like it's synchronous. Of course looping isn't
something you would want to do without a non-blocking wait() function which
doesn't exist. Again, many if not most designs should be able to be
implemented with asynch functionality - it's mostly just a different design
mindset.
>> The java version requires only one element to be added to the page, the
applet.
>> The js version requires a pool of elements to be added and with the
current
>> memory problems in IE, the less elements we create, the better.
The JS version only requires a pool large enough to accomodate concurrent
calls. If you make one call at a time, there will only ever be one element
created. If you make three concurrent calls, three elements will be created
but not until that moment. My experience is that IE has problems when the
elements are destroyed, not created, and that's why I chose to use a
reusable pool rather than to dynamically destroy the elements after use.
>> The java version allows for either HTML or JS to be returned.
That's all a matter of serialization done in javascript at either end. I
chose not to include that as a base function of JSRS but to allow it to be
added by the user. If you use MS's uneval() object serialization routines
or similar available routines, you can pass stringified JS objects with
JSRS. Object marshalling is a pretty advanced use of remote scripting,
though. There's a lot of useful stuff you can do just sending scalar values
to the server and receiving back serialized recordsets, for instance.
Wouldn't want to throw out those babies with the bathwater.
>> The loadpanel was never designed for sending large amounts of data to a
server.
>> It remains an issue that cannot be resolved without a mess of timeouts
and
>> cookies and until IE6 hits the shelves, there is NO reason to stop using
java.
True - that is, if the java piece is currently working for you. For Macs
without scriptable java applets, or for organizations with firewalls that
disallow java applets, this can be problematic. That's where the reason
lies - cross-platform issues and firewall friendliness.
I don't mean to be flippant and simply to trot out an answer to every
challenge. My main thrust is just to keep things simple. I don't think
JSRS suits every need, but I also don't think most needs exceed its
capabilities. Perhaps exactly because of its lightness is needs not be
integrated with DynAPI at all but can be added by a developer as needed as a
separate deal.
If you're going to send large amounts of structured data back and forth,
require synchronous calls, and you're worried about memory management being
in your control, maybe a browser-based client isn't what you need. If a
browser solution is required, perhaps Java, a plug-in or Active-X applet
would best provide for those advanced levels of control. Otherwise, for a
heavyweight application, a native client can give you all the control you
want.
- Brent -
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
