The OCC mechanisms include an area on disk at the Url curl://local-data for the OCC applet to write to. This directory is based on the curl-root of the applet, and is private to applets
that share the same curl-root. There is not any provided APIs to help manage that data, and there are many different ways that you might want to manage synchronization, some of the pretty simple, some of them pretty complex. For example the occ-root-installer code uses a very simple one of reading a curl-contents.txt file and checking the timestamp in that against the timestamp already copied to local disk. A similar mechanism is do-able in just a few lines. Synchronizing mail messages from an IMAP or POP server would require much more sophisticated code. Also with the Nitro beta (and eventually in the full release of that) you can use SQLite to make a database file in curl://local-data and manage synchronization with some SQL code. (You can also use SQLite in 6.0 if you have an applet that runs privileged, in either case see the Curl CDK.) Also if you don't need to be sure that the
data from a given Url is available, but you would like to use it if it is, then cacheable content that an applet accessed while connected, will sometimes still be in the HTTP cache and
can be accessed by an offline/disconnected applet. (If the applet wants to be sure that it doesn't cause the machine to dial-up the internet then it can use with-file-caching-style "only-from-cache".)
An applet can have some static data that is downloaded as part of the OCC install and update, and that is managed as described in the occ-root-installer and occ-module-installer docs.
the CSPD for unprivileged applets has a limit of 256k, but you can store an unlimited amount of data in curl://local-data.
As Duke noted pcurl is the only code hiding available, but there is no difference in code hiding between OCC and regular applets. I suppose that you could do encryption of source code
and then use evaluate to run the decrypted code, but a dedicated user could still see the code in memory once it was decrypted. For any computer language, don't ever count on the code being secret for any real security, because any code can be disassembled or watched from a debugger.
Not yet, although you can also look at some of the Nitro demos posted to developers.curl.com to see how some OCC applets handle some of these issues.

In Curl, all source code is compiled on the client whether in an OCC application or a regular Curl applet. The compressed and obfuscated pcurl format can be used in both cases to make it harder for someone to reverse-engineer your source for all types of Curl deployments but it is not foolproof. Of course, it is impossible to prevent reverse-engineering of any code that you allow to run on a machine not controlled by you, so you should never allow any top-secret code to run on any client-side platform. Fortunately, most companies don't have very much, if any, code that is so sensitive they can't risk any possibility of reverse-engineering on the client machines on which they will be installed.

What OCC gives you is a way to install a Curl application on a machine and run it outside of a browser much as you would a regular compiled desktop application, while retaining Curl's sandbox security model.

Thank you all friends. Now I have a better understanding about OCC.

Lets again come back to the main question, How to manage which data, should be downloaded along with code ?

Is it controlled by "occ-root-installer's" "curl-contents.txt" file ?
Means what ever the file we will specify those will only be downloaded to client's m/c.
If yes, then we will have to store the application DATA as Files at server ?
Or can we put a database at web server and will tell "occ-root-installer" to fetch a particular table or a particular set of records ?

Need more detail info about controlling the DATA that gets downloaded for an OCC application and about "occ-root-installer".

Thank you in adv.

Thank you Duke.

Lets keep synchronization aside for a moment and lets talk about only static data.
As the documentation for OCC says.... An OCC application gets downloaded to client m/c along with few application data.
So, I just wonder the meaning of DATA here. Means how it knows which data; where we are specifying the source/size of data ?
I'm not seeing any thing inside "occ-root-installer".

Lets say my OCC application needs 10 rows of read-only static data from a database table from webserver. So where I'll have to mention this in an OCC application. Will it store the data locally if one of my applications source file calls a method to fetch 10 rows from a database like "Select * from sample where row_count < 10" ?

I'm sorry, if I'm going off topic.

Thank you

Good question. If you have the static data in a file, then that can be part of a project that the IDE deploys for OCC, which will take care of some of the details about the curl-archive.car and curl-timestamp.txt files.

If the data was not initially available to be deployed as a file in the IDE's project, then you will have to take care yourself of storing it in a local file. OCC applets are able to read and write files in a "sandbox" area of the local disk which is referred to by the URL curl://local-data/. That sandbox of local storage is only accessible to the applet and other applets from the same web server directory, unless you take steps to make it shared by a larger group of applets. So after the OCC applet has been installed, the code you wrote in the applet would read data from the network, and then you would also have written code to store the data in a format of your choice to some file like curl://local-data/my-rows.db

For some types and amounts of data, the Curl persistent-data API could be an alternative to writing to files in curl://local-data/ , but that would also be the same kind of code you would have to write yourself.

The other thing that affects these choices is if the applet is going to be modifying this data, and then the developer has to make some decisions about how to manage the changed data - whether it needs to be sent back to the server, and how to avoid losing your changes if you are going to be getting some updated data from the server. Right now, Curl does not have built-in support for organizing the synchronization.