Hi David,

I would very carefully evaluate the need to move logic and processing to the client. From a development perspective this makes development of a site manyfold more complex, because designing well written, well behaved and maintainable client script code is a task left to the Google's of this world (ie. not very many developers have that skill and even those that do struggle with it).

The new ClientScriptCallbacks in ASP.NET 2.0 are interesting although I think the implementation is a little disappointing in a number of ways. I posted a BLOG entry about this stuff today: http://west-wind.com/weblog/posts/2302.aspx

In fact, I much prefer the approach taken by Ajax.NET (http://ajax.schwarz-interactive.de/csharpsample/default.aspx)

>I would like advice for strategies for putting my client workstations to work. If anyone has any experience with remote scripting, plug-ins, or knows of other technologies and could share their experience and good resources, I would really appreciate it.

I guess one question I would have is: What is the motivation for this? While some client side usage can be useful for the most part pure Web interfaces work well. I would say that the vast majority of 'AJAX like behaviors' fall into the 'cool' but not necessary bucket...

+++ Rick ---



>I am anticipating writing a web app within the next year. (We are working on the business layer now.)
>
>The web app will be run on an intranet, viewed in IE, all on PCs running Windows 2000 or later (so all will be .NET capable). I am lucky to know a lot about the environment in which the web app will be run.
>
>I want strategies for pushing some of the processing responsibility onto the client workstation, to optimize use of the web server. The app will be for data entry, so the middle layer is mostly business logic for getting data in and out of the database, crunching it in-between. At the very least, I would like to handle all submission validation on the client, from "field can't be empty" maybe even to "Chicoga is not a city in Illinois", etc.
>
>The options that I am looking at now are JavaScript, remote scripting, and browser plug-ins. I would need to know how these options limit the future ability of my app to run in other contexts. I don't want to use Java applets or Click-Once.
>
>I know that JavaScript/JScript/ECMA interpreters vary between browsers and may require coding to multiple targets.
>
>I know that coding a browser plug-in would only be supported by the target browser on the target platform.
>
>I know very little about remote scripting.
>
>
>Thanks.