About the OCC feature, what's the ...

Up to Discussions in Ask-the-Expert

This Question is Answered

14 "helpful" answers available (3 pts)

8 Replies Last post: Jun 12, 2008 2:19 AM by tdeng

About the OCC feature, what's the necessity for running an OCC-ed applet from a web server ?

Jun 3, 2008 7:15 AM

tdeng 35 posts since
Oct 17, 2007

According to the Curl documentation, OCC enables the end user of your application to store a copy of the application on the local hard disk and access it when not connected to the Web server. The OCC application runs locally in the Curl RTE using the stored Curl source and other application data.

As you know, the local copy of an OCC applet will be updated whenever it's online copy is (if only the applet will be running online), Then there is a question about how an occ applet could run(start up) more efficiently(quickly).

Suppose

a) my network is always online
b) my applet has updated packages/resources each time before I run it
c) my Curl Control Panel is set to "force to synchronize all applets" in the General tab(this is case commonly used in Japan).

I would provide two ways to run this applet.

1. Run this applet just as what the document told me.

that is to say, using the curl://occ/http://www.myserver.com/myapplet.dcurl to run this applet.
then the following processes will happen:
- (time 1) check update for car file, and download car file and unpack it to curl://occ-local/http://www.myserver.com/
- (time 2) check all the updates for package files/other resources
- (time 3) compile the updated packages
- (time 4) run (the online copy) and show this applet .

2. Run this applet in my own way:

I created an applet used for downloading the car file while not run it's online applet with only two lines(suppose my {applet xxx} declaration is correct):

{do {occ-install-or-update occ-root-installer}} \\ {browse-url {url "curl://occ-local/http://www.myserver.com/myapplet.dcurl" }}

This will ensure that I always run the latest application I can access, while locally! Which means, I need not run the online copy at all, I need not take extra time to donwload/update those pcurl/resource files again, which are all already included in the car file.

In this way, an applet will run with the following steps:

(time 1) check update for car file, download car file and unpack it to curl://occ-local/http://www.myserver.com/
(time 3) compile the updated packages
(time 4) run (the local copy) and show this applet.

So, now you can see, (time 2) is saved !

in fact there are other merits for the second approach, like only one copy of package caching for this applet will be created, won't break even if the network is down during running this applet when dynamic loading is used.

I'm confused by the current OCC feature because of the above description, any explanation?

Thank you!

Tags: occ, package-caching, offline, update

wbardwell 46 posts since
Oct 31, 2007

1. Re: About the OCC feature, what's the necessity for running an OCC-ed applet from a web server ? Jun 3, 2008 1:55 PM

The Nitro betas do OCC somewhat differently than 6.0 does. So I think that many of your concerns will be solved in 7.0.

First, setting the force synchronize option will often slow applets down, this should only be done by developers. And when applets are deployed, the resync-as-of and the curl-timestamp.txt (for OCC applets) does need to be kept up to date. We may add some new options later on in 7.0 to make that easier.

What you describe in 1and 2 is a reasonable way to make an OCC applet work in 6.0, although you should only re-launch when the applet is not already running from a local Url. In fact that is basically what the 7.0 RTE (which you can see in the Nitro betas) does for you. In 7.0 an OCC applet can update even when not run from an http:/https: Url, and it will be relaunched from the updated local files whenever it has been run from an http:/https: URL, or when the local files have been updated.

In 6.0 we basically just wanted to make the applet work completely normally when online, but we decided that running from the local copy did have a lot of advantages, so we are changing it in 7.0.

tdeng 35 posts since
Oct 17, 2007

2. Re: About the OCC feature, what's the necessity for running an OCC-ed applet from a web server ? Jun 3, 2008 7:02 PM

in response to: wbardwell

So I think that many of your concerns will be solved in 7.0.

That's a good news.

setting the force synchronize option will often slow applets down, this should
only be done by developers.

True, and I think I need to revise my description. Most applets developed with ProActive(ERP package from SCS) are deployed without a resync-as-of setting for their own reason. While there are also many projects that use resync-as-of just as what you suggested.

In 7.0 an OCC applet can update even when not run from an http:/https: Url,
and it will be relaunched from the updated local files whenever it has been run
from an http:/https: URL, or when the local files have been updated.

Does this mean the online applet hosted on the server will never be launched any more if it's a 7.0 OCC-ed applet ?

Another concern from me is what the current car file should be for OCC applets.

Maybe I have mentioned before long time ago, since there is a chance for improving the OCC feature, I decide to talk it here again.
The IDE now supports deploying project with OCC enabled, but this standard way to deploy OCC-ed applet produces only one car file, which means whenever there is any changes (including pakcage changes, resource files like an image file changes), a new car file consists of all pakcages and all resource files (no matter they are actually updated or not) will be created, leading to the face that all client machines running this applet will have to download the new car file and unpack everything another time just for updating maybe only one small updated image file.
This is bad.
Is there any plan for changes of OCC feature that updating for local copy will be done according to the necessity of each file ? Or any other idea ?

wbardwell 46 posts since
Oct 31, 2007

3. Re: About the OCC feature, what's the necessity for running an OCC-ed applet from a web server ? Jun 4, 2008 7:54 AM

in response to: tdeng

Does this mean the online applet hosted on the server will never be launched any more if it's a 7.0 OCC-ed applet ?

If there is no local copy of an OCC applet, then it launches from the http:/https: Url. When the applet calls occ-install-or-update it will install or update and then relaunch the OCC applet from the local copy (if it was installed or updated). But it will not launch the online version otherwise unless you load the applet by a Url that does not have the curl://occ prefix.

Another concern from me is what the current car file should be for OCC applets.

Maybe I have mentioned before long time ago, since there is a chance for improving the OCC feature, I decide to talk it here again.
The IDE now supports deploying project with OCC enabled, but this standard way to deploy OCC-ed applet produces only one car file, which means whenever there is any changes (including package changes, resource files like an image file changes), a new car file consists of all packages and all resource files (no matter they are actually updated or not) will be created, leading to the face that all client machines running this applet will have to download the new car file and unpack everything another time just for updating maybe only one small updated image file.
This is bad.
Is there any plan for changes of OCC feature that updating for local copy will be done according to the necessity of each file ? Or any other idea ?

You can deploy an OCC applet using a curl-contents.txt file that just lists the files to copy down, and if those files are still in the HTTP cache, and an update of the applet only changed a few files, then that would update more quickly than a curl-archive.car based OCC applet would update. An OCC applet could also use occ-module-installer which would only update the modules that have actually changed.

It is also fairly simple to write your on OCC installer proc, all of the magic permissions and locking is in occ-install-or-update. So if you had an applet that wanted to update one file very frequently, you could write an installer that just calls occ-root-installer and then downloads the file that gets updated frequently. Or you could just load the files that get updated frequently to curl://local-data. Or you could write a full custom installer that uses it's own way of figuring out what files need
to be updated. But basically we figured that most applets would change many files when they were updated, so just using one big file would be handy, fast, and simple. But we could add another installer proc that used another scheme, or applet developers can write their own.

tdeng 35 posts since
Oct 17, 2007

4. Re: About the OCC feature, what's the necessity for running an OCC-ed applet from a web server ? Jun 10, 2008 4:39 AM

in response to: wbardwell

That's true that using only one big file could be handy and simple, but there are many projects that are divided into two parts, one includes framework packages, the other includes screens/business logic packages, while the latter are frequently updated, the former is less likely being changed after being released.
For these cases, a more flexible OCC updating feature is desired than overwriting every file by unpacking everything from one big file.

Adding this feature to the current IDE certainly takes developing efforts for your product team, but for the developers, I believe that will be a great improvement for deploying OCC-enabled applets.

I know there are many APIs to be used to customize occ-root-installer, but that need each project learn this technique, while there is lack of tutorials for doing so. So what I'm concerning is why not provide a convient way for deploying OCC-enabled applets with partially updating, as a standard feature of the IDE, which will not bother developers any more having to dig out how to deploy their projects in the way they want, so that they could concentrate on application developing.

wbardwell 46 posts since
Oct 31, 2007

5. Re: About the OCC feature, what's the necessity for running an OCC-ed applet from a web server ? Jun 10, 2008 9:13 AM

in response to: tdeng

occ-module-installer will allow separating an applet into some library packages and some files for a particular applet, and only the modules that have changed will need to be redownloaded to be update, so the basic case that you are talking about can be handled that way. And as I said, although the IDE doesn't generate everything for you, a curl-contents.txt file is also a way to handle that sort of case. But we will certainly think about adding further built-in ways to support installing an OCC applet.

The reason that we haven't added a fine grained update format for OCC is that we haven't heard anyone insist that they needed it, and it will be more complicated for the developer to manage properly, even if the IDE tries to do some of the work.

fukuta 105 posts since
Oct 17, 2007

6. Re: About the OCC feature, what's the necessity for running an OCC-ed applet from a web server ? Jun 10, 2008 9:52 PM

in response to: wbardwell

I couldn't understand how to use occ-module-installer. For instance, how to create curl-modules.txt using IDE or what I should supply for the module parameter of occ-module-installer.
I think it is useful if that details will be well documented.

wbardwell 46 posts since
Oct 31, 2007

7. Re: About the OCC feature, what's the necessity for running an OCC-ed applet from a web server ? Jun 11, 2008 9:19 PM

in response to: fukuta

It certainly needs more documentation. I think that the module stuff will just happen if you use delegate-to to delegate to another packages manifest. (And then deploy for OCC.) The OCC deploy should also support generating curl-contents.txt and doing that style of OCC deploy, but it doesn't for now. You can also write a little mini-deploy script yourself using create-curl-modules-file. (I think that the modules are just directory names relative to the curl-root.)

tdeng 35 posts since
Oct 17, 2007

8. Re: About the OCC feature, what's the necessity for running an OCC-ed applet from a web server ? Jun 12, 2008 2:19 AM

in response to: wbardwell

As a fact, we don't have many users who use OCC feature in the past, and we now have customers who need OCC feature. Nitro (beta? )is also released as a hot spot, I think it's time for you to implement more user/developer friendly details of OCC feature.

Thank you for your valuable responses.

This Question is Answered

About the OCC feature, what's the necessity for running an OCC-ed applet from a web server ?

Jun 3, 2008 7:15 AM

Actions

More Like This