From: Goldsack, P. <pat...@hp...> - 2005-03-16 13:38:03
|
=20 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.=20 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...=20 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=20 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: sma...@li... [mailto:sma...@li...] On Behalf Of Steve Loughran Sent: 16 March 2005 12:01 To: Itamar Shtull-Trauring Cc: sma...@li...; smartfrog-developer Subject: Re: [Smartfrog-support] Versioned configuration Itamar Shtull-Trauring wrote: > Hi, >=20 > I'm looking at designing a system which may end up being built on=20 > SmartFrog. There are various applications, policies for running them,=20 > 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=20 > require DataFormat v3.6 which it gets from Bar v2.4 running on Host B." >=20 > Actions might involve: > 1. adding a new version to the list of available versions for a=20 > program (or a data flow, etc.) 2. Changing config for specific machine > to use new version. This should figure out using dependency tree what=20 > else needs upgrading, and upgrade those if possible. E.g. "Foo v1.2=20 > requires the Foo1.2 rpm to be installed so do that, which then cause=20 > Bar on same machne which depends on that RPM to be upgraded as well",=20 > or "Foo v1.2 requires Dataflow v1.3 instead of v1.2, but new config=20 > doesn't set up this so complain." > 3. Run the upgrade, allowing manual intervention if possible. >=20 > 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=20 > with it though, so I am unclear which parts would be a good fit. >=20 > I guess my main question is, could the configuration language be=20 > extensible to support the concept of versioning and dependencies on=20 > versions, and would it be possible to easily add new configuration at=20 > runtime? >=20 yes, it can and should be version aware. One problem with versioning is that you soon end up trying to describe=20 the rules "version(A)>1.2 and version(A) < 1.6.2 or (version(B)=3D2.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=20 with the maven repositories; you will be able to say you need version=20 2.6.2 of xerces, 3.8.1 of junit, etc, and they will be downloaded=20 (cached), validated, etc. You wont have full version logic, but you can at least control versions=20 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=3D6595&alloc_id=3D14396&op=3Dclick _______________________________________________ Smartfrog-support mailing list Sma...@li... https://lists.sourceforge.net/lists/listinfo/smartfrog-support |