You can't truly protect a JavaScript file because ultimately the browser needs to be able to run interpret the JavaScript to execute it and that means plain text.

The best way to 'encrypt' JavaScript is to strip out all white space and have a tool obfuscate the code. There are tools you can find for this online.

Just like anything - protection is never perfect and people who really want it can get it... I would question whether there's something really unique about what you're doing anyway. Most likely the JScript file contains some UI logic and frankly I doubt that anybody will care about that enough to even bother to look at the file... It's just not worth worrying about this sort of thing.

Aren't you one of the people pushing Open Source ideas in the first place? Isn't that against the whole concept in the first place? <g>

+++ Rick ---


>I would like to distribute an application that includes an IE client (HTM and JS pages). It also includes a server.
>
>There are also JavaScript files (JS) that would be part of the "client" module. Most of the JavaScript functions are offered in a JavaScript function object container that uses an IE documentID as the parent reference.
>
>1) Once a JavaScript file is referenced (href), my assumption is that is is cached on the browser's desktop and does not use a "refresh" cycle to "re" address the JS file - Is that true?
>
>One of the JS files is very special. I would prefer not to distribute it, but instead, have the client [module] reference this [particular] file on my server.
>
>I am used to using relative addressing on the server drives. Could I deliver my IE client module such that "one" of the JS files would be located [and addressed] on my server?
>
>Would I use a full href URL for that?
>
>Thanks