I'd like to sum up current status and thoughts of hotswapping fantom code (including pods). Does this issue really depend on URI and FFI namespaces ( #720, #934, #905)?
I'm still using the loading technique from the example code for both fantom and js generated code but it is a bit limited. The new code always have to be loaded under a new unique pod name. This accents some problems (mainly sharing type definitions and dependencies) regardless if the pod name is some random string or a script versioned name (as done in Env native code).
What is our aim really? Do we want to target this issue for 1.0?
brianWed 16 Jun 2010
Hot swapping pods actually could means lots of things...
Reloading scripts works well and is simple because each version of the script essentially becomes a new unique pod. Soft references are used by the runtime so that eventually old pods whose classes are no longer be used will get GC'ed.
Hot swapping named pods comes in two flavors: those external to the core runtime in the standard distro and those handled externally. For example if Fantom is running on an OSGi platform then you could get that functionality from OSGi. Or if a Fantom application was running in a J2EE application server most of those support reload the app.
With regards to what might be built into the core: named pods are different because other pods may depend on them and do complicated things like subclass from their types. So hot swap at the pod level can get complicated. The first step we've considered is to hot swap only on pods with no dependencies (a leaf in the depends tree), and I did a bit of design work on this case. It is not something I am expecting for 1.0 (in general some of the other core infrastructure like Java annotations, etc is more important).
Another angle is just the raw start-up time of the application. Start-up time for wisp tends be just a couple 100ms, and a good chunk of that is the JVM startup. At those speeds you are talking about the time it takes to switch from your editor to the browser to test, assuming you can automate the restart to avoid another context switch.
zyhongMon 27 Sep 2010
@brian. I think hot deployment is highly desired for scalable enterprise projects. For such kind of projects, the web server will host lots of web applications/services and definitely bring down all the services just because of changes on one application/service is not acceptable. It is well understood that hot swap is hard. However, it would be very helpful if we could make some special pods (e.g. pod implement service) dynamically loaded at runtime hot swappable. I guess this is easier to attack and I guess that is basically what osgi or AppDomain do.
katox Tue 15 Jun 2010
I'd like to sum up current status and thoughts of hotswapping fantom code (including pods). Does this issue really depend on URI and FFI namespaces ( #720, #934, #905)?
I'm still using the loading technique from the example code for both fantom and js generated code but it is a bit limited. The new code always have to be loaded under a new unique pod name. This accents some problems (mainly sharing type definitions and dependencies) regardless if the pod name is some random string or a script versioned name (as done in Env native code).
What is our aim really? Do we want to target this issue for 1.0?
brian Wed 16 Jun 2010
Hot swapping pods actually could means lots of things...
Reloading scripts works well and is simple because each version of the script essentially becomes a new unique pod. Soft references are used by the runtime so that eventually old pods whose classes are no longer be used will get GC'ed.
Hot swapping named pods comes in two flavors: those external to the core runtime in the standard distro and those handled externally. For example if Fantom is running on an OSGi platform then you could get that functionality from OSGi. Or if a Fantom application was running in a J2EE application server most of those support reload the app.
With regards to what might be built into the core: named pods are different because other pods may depend on them and do complicated things like subclass from their types. So hot swap at the pod level can get complicated. The first step we've considered is to hot swap only on pods with no dependencies (a leaf in the depends tree), and I did a bit of design work on this case. It is not something I am expecting for 1.0 (in general some of the other core infrastructure like Java annotations, etc is more important).
Another angle is just the raw start-up time of the application. Start-up time for wisp tends be just a couple 100ms, and a good chunk of that is the JVM startup. At those speeds you are talking about the time it takes to switch from your editor to the browser to test, assuming you can automate the restart to avoid another context switch.
zyhong Mon 27 Sep 2010
@brian. I think hot deployment is highly desired for scalable enterprise projects. For such kind of projects, the web server will host lots of web applications/services and definitely bring down all the services just because of changes on one application/service is not acceptable. It is well understood that hot swap is hard. However, it would be very helpful if we could make some special pods (e.g. pod implement service) dynamically loaded at runtime hot swappable. I guess this is easier to attack and I guess that is basically what osgi or AppDomain do.