RE: Versioned configuration

 
Excellent questions - unfortunately with rather less excellent answers!

There are many issues with versioning and burying a specific concept of
this into the core language or run-time. 

Languages which try to include versioning as part of the main text have
inevitably regretted the decision. Typically it is more successful to
have the notion of a build-time configuration management system to pull
together the right parts in a build of a specific version of the
delivered system. CVS is bad at this, subversion a little better,
ClearCase somewhat over complicated... 

I know of one project which has used the SmartFrog language itself to
described the versions of various modules that needed to be put together
to create different versions of a product and this was passed to a make
engine to build the system. I think this is a better solution and I
would not include version dependencies in the textual descriptions that
are part of the delivered syetem itself (this can always be done through
a naming scheme if really required).

In addition to handling the different versions of the descriptions,
there are two other aspects that should be considered:

1) the version of the SF daemon 
2) the version of the various classes and configuration descriptions

In the first, there are two aspects: the root daemon and the
sub-dameons. The first is a problem that we have yet to find a really
good and convincing solution, the other we are going to fix in the next
but one major release - giving far more control over the libraries and
code used in the creation of a sub-process. The the current system we
are mostly restricted to a clone of the root daemon, though can set some
codebase attributes. Thus updating a sub-process version will involve
downloading the new jar files and restarting the daemon with these new
jar files. The root process is a little trickier, but not impossible to
do in a similar way - we may try to provide support for this.

The problem with the components of the application is that java is not
great at handling multiple versions of classes. One trick is always to
run apps in a sub-process and download the specific classes for a
version of an application into that process - creating a different
process when a version upgrade is required. When we release the next but
one major version, we will also provide greater control over class
loaders and the ability to unload classes which provides other
possibilities.

As for how to transition apps from one version to another - this is an
application-specific thing. We provided the workflow specifically as a
first attempt at allowing the distributed sequencing and coordination of
precisely that process. How to move internal state from component to
component with possible refactoring of the components is not a generally
templateable thing - though there may exist some standard patterns that
could be captured in some way through standard templates and components.
If so we have not provided them out of the box but would love
suggestions (and better still code).

So, only partial answers to the general versioning issue, but we would
be interested in any specific issues you have.

Patrick

-----Original Message-----
From: smartfrog-support-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:smartfrog-support-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of
Steve Loughran
Sent: 16 March 2005 12:01
To: Itamar Shtull-Trauring
Cc: smartfrog-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; smartfrog-developer
Subject: Re: [Smartfrog-support] Versioned configuration

Itamar Shtull-Trauring wrote:
> Hi,
> 
> I'm looking at designing a system which may end up being built on 
> SmartFrog. There are various applications, policies for running them, 
> and data flows that go between various applications, all of which need

> to be versioned. For example, "Host A runs a Foo v1.2 server that 
> require DataFormat v3.6 which it gets from Bar v2.4 running on Host
B."
> 
> Actions might involve:
> 1. adding a new version to the list of available versions for a 
> program (or a data flow, etc.) 2. Changing config for specific machine

> to use new version. This should figure out using dependency tree what 
> else needs upgrading, and upgrade those if possible. E.g. "Foo v1.2 
> requires the Foo1.2 rpm to be installed so do that, which then cause 
> Bar on same machne which depends on that RPM to be upgraded as well", 
> or "Foo v1.2 requires Dataflow v1.3 instead of v1.2, but new config 
> doesn't set up this so complain."
> 3. Run the upgrade, allowing manual intervention if possible.
> 
> Parts of this are out of the scope of what SmartFrog can do, I think.
> I'm still reading documentation and getting ready to start playing 
> with it though, so I am unclear which parts would be a good fit.
> 
> I guess my main question is, could the configuration language be 
> extensible to support the concept of versioning and dependencies on 
> versions, and would it be possible to easily add new configuration at 
> runtime?
> 

yes, it can and should be version aware.

One problem with versioning is that you soon end up trying to describe 
the rules "version(A)>1.2 and version(A)  <   1.6.2 or (version(B)=2.0 
and version (A)>1.5)" or similar. That is, it's  not always enough to
declare minimum version that works.


I want to do a repository component for java jars that is compatible 
with the maven repositories; you will be able to say you need version 
2.6.2 of xerces, 3.8.1 of junit, etc, and they will be downloaded 
(cached), validated, etc.

You wont have full version logic, but you can at least control versions 
of libraries just by updating your declaration of JAR file versions (and

SHA1 digests, for security).

will this do?

-steve


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Smartfrog-support mailing list
Smartfrog-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/smartfrog-support


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click