I'm personally fond of vcXMLRPC - http://www.vcdn.org/Public/XMLRPC/ - and have used it successfully in several projects, an ASP application and a Struts-based application. I've heard of others, but that one has been good to me as it works with IE 5.5+ and Mozilla 1.0+.
This also seems to be a good list of non XML-RPC remote scripting for Javascript: http://www.ashleyit.com/rs/main.htm I've never understood why XML-RPC and remote scripting in general haven't been more prevelent in web applications. The main limitation is a semi-recent browser, but that shouldn't be an issue in most web applications, especially within intranets. The excellent performance and developmental simplicity make web applications viable for more complex tasks. Don On Sat, 30 Oct 2004 00:18:08 -0400, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > It sounds like what your saying is that such a beast already exists... > I'm looking now at the XML-RPC site at http://ws.apache.org/xmlrpc/, > specifically the link to Client Classes... Is this what your referring > to? If so, I think this is dealing with writing a Java-based client, > not Javascript objects. Assuming that's not it though, can you point me > in the right direction? I'm most definitely interested! > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > Don Brown wrote: > > On Fri, 29 Oct 2004 23:52:49 -0400, Frank W. Zammetti > > <[EMAIL PROTECTED]> wrote: > > > >>Argh, posted to the wrong list! > >> > >>Well, in all honesty, this isn't something that was initiated by me, > >>I've never had a thought of passing objects back and forth, so I'm not > >>sure I can give you a real, concrete use case that would explain it. I > >>certainly hear what your saying about XML. I myself have done that very > >>thing in place of something like this. > >> > >>I think the point that makes this interesting is the idea of objects > >>end-to-end. Think of it almost like RMI between a browser-based client > >>and a Java-based back-end. As in RMI, an object gets "flattened" into > >>some data representation, transmitted and reconstituted on the receiving > >>end. But on both sides of the conversation you have an object. > >> > >>If what your asking is why not just pass XML representing the data > >>instead of a representation of an object, then I'd say because then you > >>have to know about some intermediary interpretation of an object, namely > >>XML. It would kind of be like saying that instead of using RMI, why not > >>just serialize an object's data as XML and transmit that, then parse it > >>on the other end... Certainly that's done every day, but RMI is I think > >>more elegant in that your always dealing in objects, and conversion for > >>the sake of transport is done transparently. > > > > > > That is not necessarily true. If you use XML-RPC, specifically one of > > the several client-side Javascript libraries for XML-RPC, your > > application, both on the client and server side, never have to touch > > XML. The XML-RPC library automatically handles > > serialization/deserialization as does the server side XML-RPC library > > (Apache has a great one for this). I use XML-RPC in several > > applications for the specific reason that I never have to deal with > > XML, yet I get rich communication between my web application and > > server. > > > > Don > > > > > >>I know what your saying about tying to Javascript, but I'm not sure > >>there's too many client-side scripting languages to worry about. I > >>mean, Javascript and VBScript are all I can think of, and although it's > >>been a while since I worked with VBScript, I don't recall there being an > >> object creation mechanism like in Javascript, so I'm not sure how big > >>a concern it is. Certainly I think it's safe to say that Javascript is > >>by far the most popular client-side scripting language, and therefore a > >>solution that is going to cover 75% of applications is probably useful. > >> > >>-- > >>Frank W. Zammetti > >>Founder and Chief Software Architect > >>Omnytex Technologies > >>http://www.omnytex.com > >> > >>Martin Cooper wrote: > >> > >> > Just curious, and I'm sure I'm missing something (which is why I'm > >> > asking!), but why would you want to do this when there are XML based > >> > solutions there for the using, free, and that don't tie you to > >> > JavaScript? > >> > > >> > Thanks. > >> > > >> > -- > >> > Martin Cooper > >> > > >> > > >> > On Fri, 29 Oct 2004 22:31:32 -0400, Frank W. Zammetti > >> > <[EMAIL PROTECTED]> wrote: > >> > > >> >> On the later idea, I intend to put together a proof-of-concept next week > >> >> when I get back to the office. I have some family engagements this > >> >> weekend that will keep me from getting started, and on Tuesday I take > >> >> the first exam for my SCEA (not to mention the election!), but I have > >> >> some spare cycles at work currently so I should pretty much have the > >> >> rest of the week to play. > >> >> > >> >> I only mention this because while I obviously can't stop anyone else > >> >> from beating me to the punch, I do intend to persue this, so if you have > >> >> any other itches to scratch, go for them, leave this one for me if you > >> >> would :) > >> >> > >> >> -- > >> >> Frank W. Zammetti > >> >> Founder and Chief Software Architect > >> >> Omnytex Technologies > >> >> http://www.omnytex.com > >> >> > >> >> > >> >> > >> >> Craig McClanahan wrote: > >> >> > >> >>> On Fri, 29 Oct 2004 21:28:52 -0400, Ted Husted <[EMAIL PROTECTED]> > >>wrote: > >> >>> > >> >>> > >> >>>> That sounds great to me, Don. :) > >> >>>> > >> >>>> We already have Struts-Faces and Struts-Examples on the trunk. We > >>might as well add Struts-BSF and Struts-Flow to the mix. > >> >>> > >> >>> > >> >>> > >> >>> +1. > >> >>> > >> >>> > >> >>> > >> >>>> Struts-BSF and Struts-Flow are not part of the core, so they would > >>be not affected by a 1.2.x branch. > >> >>>> > >> >>>> -Ted. > >> >>>> > >> >>> > >> >>> > >> >>> Note that there have been two overlapping discussions about scripting > >> >>> on the lists today ... Don's stuff in Struts Flow uses a modified > >> >>> Rhino (with continutations) to do scripting on the *server* side, > >> >>> while the earlier conversation about serializing a JavaScript object > >> >>> and converting it is about scripting on the *client* side, using a > >> >>> serialized form of JavaScript objects to pass data back and forth > >> >>> through a hidden field. > >> >>> > >> >>> Both ideas are quite cool. > >> >>> > >> >>> Craig > >> >>> > >> >>> --------------------------------------------------------------------- > >> >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >>> For additional commands, e-mail: [EMAIL PROTECTED] > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> . > >> >>> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > >> >> > >> > > >> > > >> > > >> > > >> > > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
