You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Dave Brondsema <da...@brondsema.net> on 2004/02/03 15:24:52 UTC
Re: multiple skin descriptors, skin versions
On Fri, 30 Jan 2004, Marshall Roch wrote:
> Dave Brondsema wrote:
> > This makes sense to me. So the skin fetching target should get the highest
> > version compatible with the user's version of forrest. So we would need to
> > track what version(s) of forrest a given skin version is compatible with. For
> > example, skinabc 1.3 is the latest version compatible with 0.5, but there is
> > already a skinabc 2.0 which is compatible with 0.6-dev. 0.5 users shouldn't get
> > 2.0 but 0.6-dev users should.
>
> Right.
>
So each skin needs to declare what version it is and what versions of
forrest it is compatible with. We could put this in the skins.xml
along with the other info (url, name, etc) of the skin. However, the
version info needs to be self-contained in the skin and remain in a file
on the local installation of forrest. skins.xml files are temporary on
local installations.
So I propose a skin.xml definition file to be in the base directory of
each skin. It would contain the <skin> content from skinconf.xml in
addition to version information. Skins.xml would just references these
files (they would have to be available outside the .zip also for easy
fetching).
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - Calvin club
Re: multiple skin descriptors, skin versions
Posted by Marshall Roch <ma...@exclupen.com>.
Dave Brondsema wrote:
> So the f0.5 would actually mean compatible with forrest 0.5 and greater. If
> compatibility breaks at 0.8 (for example) then a skinname-f0.8-0.4.zip would
> have to be made.
>
> Would this work?
+1
--
Marshall Roch
Re: multiple skin descriptors, skin versions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
> Quoting Nicola Ken Barozzi <ni...@apache.org>:
>
>
>>Marshall Roch wrote:
>>
>>>3) Skin version based on Forrest version and revision of skin
>
>>Ok, so I guess we all agree now on 3) as proposed by Dave. :-)
>>
>>I'll see how we can get round to using Ruper and Version for this.
>
>
> I've got something almost working,
:-)
> but there's a technical difficulty in knowing
> what files to try to download. Basically forrest needs to know all possible
> forrest version numbers and all possible skin version numbers. E.G: try
> downloading:
>
> myskin-f0.6-dev-0.3.zip (not found so we try next)
> myskin-f0.6-dev-0.2.1.zip (not found so we try next)
> myskin-f0.6-dev-0.2.zip (not found so we try next)
> myskin-f0.6-dev-0.1.zip (not found so we try next)
> myskin-f0.6-dev.zip (not found so we try next)
> myskin-f0.5-0.3.zip (found!)
>
> I can easily put a prior-versions variable in forrest which we can use. But
> forrest still doesn't know what version numbers to try when downloading a
> specific skin. In the example above, it would have to know to start at 0.3 and
> also that there was a 0.2.1 release. We could put prior-versions elements in
> the skins descriptor, but that's kinda ugly. Another option, but with many
> potential problems, would be to try to get a list of files from the web server.
>
> Perhaps Ruper would be a better solution. How would it handle a situation like
> this? Does the repository publish a list of available files?
>
http://krysalis.org/wiki/Ruper :
"
How is the selection of last version done ?
The default ?VersionComparator? sorts version in the order of : major,
minor, fixe, modifierCode, modifierNumber, build But update is done only
if the new version is compatible. The rule is :
* version_tested and version_orig have same modifierCode, or are
from the same side of the modifierCodeFrontier? (default is RELEASE).
* version_orig.Major is 0 or version_tested have same Major as
version_orig.
"
AFAIK we need just to make our VersionComparator class and Ruper should
take care of the rest.
Just some extra insight on Ruper2:
Multiple Repos:
http://www.krysalis.org/ruper/config/index.html
Eclipse Plugin:
http://www.krysalis.org/ruper/eclipse/index.html
CLI:
http://www.krysalis.org/ruper/tool/quickstart.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: multiple skin descriptors, skin versions
Posted by Johan Kok <jk...@messianic.dyndns.org>.
Marshall Roch wrote:
> Johan Kok wrote:
>
>> Marshall Roch wrote:
>>
>>> I've said it before, and I just wanted to reiterate it again. An
>>> XML file listing all of the skins and each version has the potential
>>> to get huge pretty quickly. It would create a lot of extra
>>> bandwidth usage that could be avoided:
>>
>>
>> Perphaps you misunderstood my proposal: It was to used the
>> relationship information within an XML database to decide which to
>> load. The intention was not to have all skins downloaded. On the
>> contrary, once we get some nice flixible skins going, you will see a
>> proliferation of such and that is really when the database solution
>> will come into play.
>
>
> This means that each user will need to download the entire XML
> database from the server, process it, then request the particular file
> needed. After said proliferation of skins, I'm guessing that the
> database could get pretty big (1mb+?).
A serious load of relationship decriptors you want to load? How many
relationships between a skin's versions and forrest versions do you
expect? ... The relationship descriptors should be downloaded with a
CVS, not the actual skins.
>
> The whole RPC (or SOAP) transaction would be at most 10kb. A downside
> is a little more load on the server, which would probably be
> outweighed by bandwidth costs.
That would still be applicable..... The solution proposed above was
merely an easy way to store the relationships between skin versions and
forrest versions enabling the determination of which skin to use/download.
>
> --
> Marshall Roch
>
>
Re: multiple skin descriptors, skin versions
Posted by Marshall Roch <ma...@exclupen.com>.
Johan Kok wrote:
> Marshall Roch wrote:
>> I've said it before, and I just wanted to reiterate it again. An XML
>> file listing all of the skins and each version has the potential to
>> get huge pretty quickly. It would create a lot of extra bandwidth
>> usage that could be avoided:
>
> Perphaps you misunderstood my proposal: It was to used the relationship
> information within an XML database to decide which to load. The
> intention was not to have all skins downloaded. On the contrary, once we
> get some nice flixible skins going, you will see a proliferation of such
> and that is really when the database solution will come into play.
This means that each user will need to download the entire XML database
from the server, process it, then request the particular file needed.
After said proliferation of skins, I'm guessing that the database could
get pretty big (1mb+?).
The whole RPC (or SOAP) transaction would be at most 10kb. A downside
is a little more load on the server, which would probably be outweighed
by bandwidth costs.
--
Marshall Roch
Re: multiple skin descriptors, skin versions
Posted by Johan Kok <jk...@messianic.dyndns.org>.
Marshall Roch wrote:
> Johan Kok wrote:
>
>> Perhaps time to look at using XML database solution rather that
>> trying to describe everything in filenames. That could contain a
>> whole load more information than just that, e.g. document hierarchy
>> structure, which could be used to generate the site navigation, also
>> for the inclusion of plug-ins, setting of parameters, like those in
>> the sitemap etc.. Personally I believe that one can build enourmous
>> flexibility going in the direction of an XML database.
>
>
> I've said it before, and I just wanted to reiterate it again. An XML
> file listing all of the skins and each version has the potential to
> get huge pretty quickly. It would create a lot of extra bandwidth
> usage that could be avoided:
Perphaps you misunderstood my proposal: It was to used the relationship
information within an XML database to decide which to load. The
intention was not to have all skins downloaded. On the contrary, once we
get some nice flixible skins going, you will see a proliferation of such
and that is really when the database solution will come into play.
>
>
> If the Forrest server ran an XML-RPC server (there are a number of
> Java implementations, I believe), Forrest users could send an XML-RPC
> request with their Forrest version and the skin they want, and the
> Forrest server could figure out which file they need server-side and
> respond with the right file name. Then the user would grab just that
> file.
>
> --
> Marshall Roch
>
>
Re: multiple skin descriptors, skin versions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
> Quoting Nicola Ken Barozzi <ni...@apache.org>:
>
>>I have been working a nd thinking about code repositories for quite some
>>time now, and the easiest solution is to use filename metadata for versions.
>>
>>- no server requirements
>>- can use a local repo copy
>>- is resilient, as it's closest possible to the source and remains even
>>when I copy the file out of the repo
>>- it's visible
>>- easy to deploy
>>
>>I think we will stick to this till we can :-)
>
> So I think we still have a technical problem about getting a list of skins the
> server has available. Would Ruper solve this?
Yes. :-)
> Just to clarify, we don't need to bring up the issue of version compatibility
> again; I think we've got that covered by our file naming format.
;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: multiple skin descriptors, skin versions
Posted by Clay Leeds <cl...@medata.com>.
Dave Brondsema said:
> On Tue, 17 Feb 2004, Clay Leeds wrote:
>> Dave Brondsema said:
>> > Quoting Nicola Ken Barozzi <ni...@apache.org>:
>> > So I think we still have a technical problem about getting a list of
skins
>> > the server has available. Would Ruper solve this? The only other
options I
>> > see are to manually maintain a text file that lists all the files, or
manually
>> > maintain the skins descriptor to explicitly list version numbers.
>> >
>> > Just to clarify, we don't need to bring up the issue of version
>> > compatibility again; I think we've got that covered by our file
naming format.
>> > --
>> > Dave Brondsema
>>
>> Is it possible to have the best of both worlds: 1) a local copy and 2) a
>> server-based version. The local copy would be used *only* if a
>> connection
>> could not be made over the internet to the server-based version.
>>
>> Web Maestro Clay
>
> You can override forrest.skins.descriptors in $HOME/forrest.properties or
> the projects' forrest.properties to look in multiple locations (including
> locally). For example:
>
> forrest.skins.descriptors=http://xml.apache.org/forrest/skins/skins.xml,file:///c:/Documents
> and Settings/dbrondse/myskins/skins.xml
>
> --
> Dave Brondsema
I understand that can be overridden. I was thinking of the dual modality
to resolve the technical problem indicated above. Further, an addition to
Forrest could be made of a variable CLI timeout argument for resolving the
host if warranted.
Just trying to think of ways to help...
Web Maestro Clay
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
Re: multiple skin descriptors, skin versions
Posted by Dave Brondsema <da...@brondsema.net>.
On Tue, 17 Feb 2004, Clay Leeds wrote:
> Dave Brondsema said:
> > Quoting Nicola Ken Barozzi <ni...@apache.org>:
> > So I think we still have a technical problem about getting a list of skins
> > the server has available. Would Ruper solve this? The only other
> options I
> > see are to manually maintain a text file that lists all the files, or
> manually
> > maintain the skins descriptor to explicitly list version numbers.
> >
> > Just to clarify, we don't need to bring up the issue of version
> > compatibility again; I think we've got that covered by our file naming
> format.
> > --
> > Dave Brondsema
>
> Is it possible to have the best of both worlds: 1) a local copy and 2) a
> server-based version. The local copy would be used *only* if a connection
> could not be made over the internet to the server-based version.
>
> Web Maestro Clay
>
You can override forrest.skins.descriptors in $HOME/forrest.properties or
the projects' forrest.properties to look in multiple locations (including
locally). For example:
forrest.skins.descriptors=http://xml.apache.org/forrest/skins/skins.xml,file:///c:/Documents
and Settings/dbrondse/myskins/skins.xml
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - Calvin club
Re: multiple skin descriptors, skin versions
Posted by Clay Leeds <cl...@medata.com>.
Dave Brondsema said:
> Quoting Nicola Ken Barozzi <ni...@apache.org>:
> So I think we still have a technical problem about getting a list of skins
> the server has available. Would Ruper solve this? The only other
options I
> see are to manually maintain a text file that lists all the files, or
manually
> maintain the skins descriptor to explicitly list version numbers.
>
> Just to clarify, we don't need to bring up the issue of version
> compatibility again; I think we've got that covered by our file naming
format.
> --
> Dave Brondsema
Is it possible to have the best of both worlds: 1) a local copy and 2) a
server-based version. The local copy would be used *only* if a connection
could not be made over the internet to the server-based version.
Web Maestro Clay
Re: multiple skin descriptors, skin versions
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Nicola Ken Barozzi <ni...@apache.org>:
>
> I have been working a nd thinking about code repositories for quite some
> time now, and the easiest solution is to use filename metadata for versions.
>
> - no server requirements
> - can use a local repo copy
> - is resilient, as it's closest possible to the source and remains even
> when I copy the file out of the repo
> - it's visible
> - easy to deploy
>
> I think we will stick to this till we can :-)
>
So I think we still have a technical problem about getting a list of skins the
server has available. Would Ruper solve this? The only other options I see are
to manually maintain a text file that lists all the files, or manually maintain
the skins descriptor to explicitly list version numbers.
Just to clarify, we don't need to bring up the issue of version compatibility
again; I think we've got that covered by our file naming format.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - student org
Re: multiple skin descriptors, skin versions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
I have been working a nd thinking about code repositories for quite some
time now, and the easiest solution is to use filename metadata for versions.
- no server requirements
- can use a local repo copy
- is resilient, as it's closest possible to the source and remains even
when I copy the file out of the repo
- it's visible
- easy to deploy
I think we will stick to this till we can :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: multiple skin descriptors, skin versions
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Marshall Roch <ma...@exclupen.com>:
> Johan Kok wrote:
> > Perhaps time to look at using XML database solution rather that trying
> > to describe everything in filenames. That could contain a whole load
> > more information than just that, e.g. document hierarchy structure,
> > which could be used to generate the site navigation, also for the
> > inclusion of plug-ins, setting of parameters, like those in the sitemap
> > etc.. Personally I believe that one can build enourmous flexibility
> > going in the direction of an XML database.
>
> I've said it before, and I just wanted to reiterate it again. An XML
> file listing all of the skins and each version has the potential to get
> huge pretty quickly. It would create a lot of extra bandwidth usage
> that could be avoided:
>
> If the Forrest server ran an XML-RPC server (there are a number of Java
> implementations, I believe), Forrest users could send an XML-RPC request
> with their Forrest version and the skin they want, and the Forrest
> server could figure out which file they need server-side and respond
> with the right file name. Then the user would grab just that file.
>
> --
> Marshall Roch
>
That seems like a good solution from a programmatic viewpoint (ours) but it adds
a significant requirement for the server. Very few sites have permissions on
their host to run an XML-RPC server. Moreover, I would like a solution that
would continue to work for local files too (using file:/ instead of http:/)
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - student org
Re: multiple skin descriptors, skin versions
Posted by Marshall Roch <ma...@exclupen.com>.
Johan Kok wrote:
> Perhaps time to look at using XML database solution rather that trying
> to describe everything in filenames. That could contain a whole load
> more information than just that, e.g. document hierarchy structure,
> which could be used to generate the site navigation, also for the
> inclusion of plug-ins, setting of parameters, like those in the sitemap
> etc.. Personally I believe that one can build enourmous flexibility
> going in the direction of an XML database.
I've said it before, and I just wanted to reiterate it again. An XML
file listing all of the skins and each version has the potential to get
huge pretty quickly. It would create a lot of extra bandwidth usage
that could be avoided:
If the Forrest server ran an XML-RPC server (there are a number of Java
implementations, I believe), Forrest users could send an XML-RPC request
with their Forrest version and the skin they want, and the Forrest
server could figure out which file they need server-side and respond
with the right file name. Then the user would grab just that file.
--
Marshall Roch
Re: multiple skin descriptors, skin versions
Posted by Johan Kok <jk...@messianic.dyndns.org>.
Dave Brondsema wrote:
>
>
>myskin-f0.6-dev-0.3.zip (not found so we try next)
>myskin-f0.6-dev-0.2.1.zip (not found so we try next)
>myskin-f0.6-dev-0.2.zip (not found so we try next)
>myskin-f0.6-dev-0.1.zip (not found so we try next)
>myskin-f0.6-dev.zip (not found so we try next)
>myskin-f0.5-0.3.zip (found!)
>
>I can easily put a prior-versions variable in forrest which we can use. But
>forrest still doesn't know what version numbers to try when downloading a
>specific skin. In the example above, it would have to know to start at 0.3 and
>also that there was a 0.2.1 release. We could put prior-versions elements in
>the skins descriptor, but that's kinda ugly. Another option, but with many
>potential problems, would be to try to get a list of files from the web server.
>
>Perhaps Ruper would be a better solution. How would it handle a situation like
>this? Does the repository publish a list of available files?
>
>
Perhaps time to look at using XML database solution rather that trying
to describe everything in filenames. That could contain a whole load
more information than just that, e.g. document hierarchy structure,
which could be used to generate the site navigation, also for the
inclusion of plug-ins, setting of parameters, like those in the sitemap
etc.. Personally I believe that one can build enourmous flexibility
going in the direction of an XML database.
Re: multiple skin descriptors, skin versions
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Nicola Ken Barozzi <ni...@apache.org>:
> Marshall Roch wrote:
> > 3) Skin version based on Forrest version and revision of skin
> Ok, so I guess we all agree now on 3) as proposed by Dave. :-)
>
> I'll see how we can get round to using Ruper and Version for this.
>
I've got something almost working, but there's a technical difficulty in knowing
what files to try to download. Basically forrest needs to know all possible
forrest version numbers and all possible skin version numbers. E.G: try
downloading:
myskin-f0.6-dev-0.3.zip (not found so we try next)
myskin-f0.6-dev-0.2.1.zip (not found so we try next)
myskin-f0.6-dev-0.2.zip (not found so we try next)
myskin-f0.6-dev-0.1.zip (not found so we try next)
myskin-f0.6-dev.zip (not found so we try next)
myskin-f0.5-0.3.zip (found!)
I can easily put a prior-versions variable in forrest which we can use. But
forrest still doesn't know what version numbers to try when downloading a
specific skin. In the example above, it would have to know to start at 0.3 and
also that there was a 0.2.1 release. We could put prior-versions elements in
the skins descriptor, but that's kinda ugly. Another option, but with many
potential problems, would be to try to get a list of files from the web server.
Perhaps Ruper would be a better solution. How would it handle a situation like
this? Does the repository publish a list of available files?
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - student org
Re: multiple skin descriptors, skin versions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Marshall Roch wrote:
> Nicola Ken Barozzi wrote:
>
>> But we don't know still if they are compatible. Hence my subsequent
>> proposal that instead of f0.5 we use the *skin contract* version, that
>> is separate from the Forrest version. We should change it when the
>> skins have to change.
>>
>> hence: skinname-0.2.jar where 0.2 is the *skin contract* version
>
> So if I am not mistaken, we have four different proposals on the table
> currently:
>
> 1) Skin version based on Forrest version
> 2) Skin version based on revision of skin
> 3) Skin version based on Forrest version and revision of skin
> 4) Skin version based on skin contract
>
> Both 2 and 4 have the same problem in that they need to keep track of
> which version of Forrest they are compatible with. #1 doesn't allow
> updates to the skin without a release of Forrest, so that's a Bad
> Thing(tm). I like 3 if used in the ">=" sense as already proposed by
> Dave. It provides a little more detail for the user so they know that
> the skin has been revised, while still also telling the user what
> versions of Forrest the skin works with. Also, if an updated skin makes
> a change you don't like, you can revert to an older version since the
> filenames are different.
Ok, so I guess we all agree now on 3) as proposed by Dave. :-)
I'll see how we can get round to using Ruper and Version for this.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: multiple skin descriptors, skin versions
Posted by Marshall Roch <ma...@exclupen.com>.
Nicola Ken Barozzi wrote:
> But we don't know still if they are compatible. Hence my subsequent
> proposal that instead of f0.5 we use the *skin contract* version, that
> is separate from the Forrest version. We should change it when the skins
> have to change.
>
> hence: skinname-0.2.jar where 0.2 is the *skin contract* version
So if I am not mistaken, we have four different proposals on the table
currently:
1) Skin version based on Forrest version
2) Skin version based on revision of skin
3) Skin version based on Forrest version and revision of skin
4) Skin version based on skin contract
Both 2 and 4 have the same problem in that they need to keep track of
which version of Forrest they are compatible with. #1 doesn't allow
updates to the skin without a release of Forrest, so that's a Bad
Thing(tm). I like 3 if used in the ">=" sense as already proposed by
Dave. It provides a little more detail for the user so they know that
the skin has been revised, while still also telling the user what
versions of Forrest the skin works with. Also, if an updated skin makes
a change you don't like, you can revert to an older version since the
filenames are different.
--
Marshall Roch
Re: multiple skin descriptors, skin versions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
> Quoting Nicola Ken Barozzi <ni...@apache.org>:
>
>>skinname-f0.5-0.3.jar (version 0.3 compatible with forrest 0.5)
...
>>Yes... err... but in my mail I also proposed that maybe the '0.3' part
>>is not needed. The rationals was that a skin has to be gotten with the
>>highest number anyway, so we can go without it altogether and simply use
>>the publish date of the file.
>>
>> hence: skinname-f0.5.jar (read on)
>
...
> If a skin is released as skinname-f0.5.zip and then significant enhancements are
> made and a new release (still forrest 0.5 compatible) is made, what should it be
> called? I don't think it should still be skinname-f0.5.zip, especially because
> that makes it difficult to know that is has been updated.
I tend to think that the file date is a good enough indication... read on...
...
>>But we don't know still if they are compatible. Hence my subsequent
>>proposal that instead of f0.5 we use the *skin contract* version, that
>>is separate from the Forrest version. We should change it when the skins
>>have to change.
>>
>> hence: skinname-0.2.jar where 0.2 is the *skin contract* version
>
> What exactly do you mean by *skin contract* version? 0.2 means what? If I saw
> a file named like that, I would assume that it is version 0.2 of the skin,
Conceded.
> and I
> have no idea what versions of forrest it is compatible with.
Hmmm... conceded as well :-)
>>In essence, what should happen is:
>>
>> - if a skin is not present
>> - get the skins descriptor
>> - get the download dir of the skin
>> - get the current forrest skin version compat
>> (in the current Forrest)
>> - look for a file named skinname-skinversioncompat.zip
>> - if found
>> - download and unpack skin
>> - add a file with the date of the zip and the version
>> in the skin
>> - if not found
>> - search for skinname.zip (best effort skin)
>> - if found
>> (do as already specified above)
>>
>>To update the skins, it does as above but downloads the skin only if the
>>remote file date is newer than the date that it wrote inside the skin.
>
> I don't think we should rely on remote file dates. It is meta-data that is
> easily lost or changed (e.g. uploading the same file again: the file gets a new
> date and the original date is lost).
Well, it's possible to change it, but again, I concede that this is what
would generally happen.
>>In this way we don't need to generate and maintain descriptors in the
>>download dirs and in the zips, and have a simple naming scheme.
>>
>>This is what I meant about Mozilla: the skins are downloadable per major
>>Mozilla version, not per skin version. In our case it would be per skin
>>version.
>>
>>WDYT?
>>
>>I hope I was clearer this time :-)
>
> I think we're making progress ...
Well, from all this the summary seems to be:
1 - we need indications about forrest and skin compatibility in robust
metadata (filename is the current best guess)
2 - the compatibility version should indicate the nearest Forrest
version to which it's compatible (nothing said though for forward
or backward compat, it's Forrest that should know)
3 - we need to keep the information available also in the deployed state
so to be able to check the repositories for new versions.
All this means one thing to me: we need a tool for it as Ant does not
cut it. In the Incubator we are incubating Apache Depot, that contains
Ruper to download artifacts from repositories, query them, and a tool
called Version that Ruper uses with which we can define our special
versioning scheme.
Here are the old sites of Ruper and Version (ATM SF seems down):
http://www.krysalis.org/ruper/
http://www.krysalis.org/version/
WDYT?
(IMHO we should slate this for 0.7, disable downloaded skin support, and
finish things for a 0.6 release)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: multiple skin descriptors, skin versions
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Nicola Ken Barozzi <ni...@apache.org>:
> Dave Brondsema wrote:
> > Quoting Marshall Roch <ma...@exclupen.com>:
> >
> >>Dave Brondsema wrote:
> >>
> >>>>IIRC I had added a filename convention too, so a skin would be for
> >>
> >>example:
> >>
> >>>> skinname-f0.5-0.3.jar (version 0.3 compatible with forrest 0.5)
> >>>
> >>>I like this. Simpler is better.
>
> Yes... err... but in my mail I also proposed that maybe the '0.3' part
> is not needed. The rationals was that a skin has to be gotten with the
> highest number anyway, so we can go without it altogether and simply use
> the publish date of the file.
>
> hence: skinname-f0.5.jar (read on)
>
No, we don't always want to get a skin with the highest number. When forrest
0.4, 0.5, and 0.6-dev users update a skin, it is quite likely that they will
download different files and only the 0.6-dev user will download the one with
the highest version number.
If a skin is released as skinname-f0.5.zip and then significant enhancements are
made and a new release (still forrest 0.5 compatible) is made, what should it be
called? I don't think it should still be skinname-f0.5.zip, especially because
that makes it difficult to know that is has been updated.
> >>I thought this was the problem. Skin version 0.3 might still work for
> >>Forrest 0.6 and 0.7, but with your proposed naming scheme, each skin
> >>would have to be re-released for each Forrest release, and bug fixes to
> >>the skin release for 0.6 would not be applied to the release for Forrest
> >>0.5.
> > If skin version 0.3 is compatible Forrest 0.5 and still works when 0.6 and
> 0.7
> > are released, we could keep skinname-f0.5-0.3.jar The fetcher could get
> the
> > skin with the highest forrest version number possible (less than or equal
> to the
> > version of forrest installed, of course).
>
> But we don't know still if they are compatible. Hence my subsequent
> proposal that instead of f0.5 we use the *skin contract* version, that
> is separate from the Forrest version. We should change it when the skins
> have to change.
>
> hence: skinname-0.2.jar where 0.2 is the *skin contract* version
>
What exactly do you mean by *skin contract* version? 0.2 means what? If I saw
a file named like that, I would assume that it is version 0.2 of the skin, and I
have no idea what versions of forrest it is compatible with.
> In essence, what should happen is:
>
> - if a skin is not present
> - get the skins descriptor
> - get the download dir of the skin
> - get the current forrest skin version compat
> (in the current Forrest)
> - look for a file named skinname-skinversioncompat.zip
> - if found
> - download and unpack skin
> - add a file with the date of the zip and the version
> in the skin
> - if not found
> - search for skinname.zip (best effort skin)
> - if found
> (do as already specified above)
>
> To update the skins, it does as above but downloads the skin only if the
> remote file date is newer than the date that it wrote inside the skin.
>
I don't think we should rely on remote file dates. It is meta-data that is
easily lost or changed (e.g. uploading the same file again: the file gets a new
date and the original date is lost).
> In this way we don't need to generate and maintain descriptors in the
> download dirs and in the zips, and have a simple naming scheme.
>
> This is what I meant about Mozilla: the skins are downloadable per major
> Mozilla version, not per skin version. In our case it would be per skin
> version.
>
> WDYT?
>
> I hope I was clearer this time :-)
>
I think we're making progress ...
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - student org
Re: multiple skin descriptors, skin versions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
> Quoting Marshall Roch <ma...@exclupen.com>:
>
>>Dave Brondsema wrote:
>>
>>>>IIRC I had added a filename convention too, so a skin would be for
>>
>>example:
>>
>>>> skinname-f0.5-0.3.jar (version 0.3 compatible with forrest 0.5)
>>>
>>>I like this. Simpler is better.
Yes... err... but in my mail I also proposed that maybe the '0.3' part
is not needed. The rationals was that a skin has to be gotten with the
highest number anyway, so we can go without it altogether and simply use
the publish date of the file.
hence: skinname-f0.5.jar (read on)
>>I thought this was the problem. Skin version 0.3 might still work for
>>Forrest 0.6 and 0.7, but with your proposed naming scheme, each skin
>>would have to be re-released for each Forrest release, and bug fixes to
>>the skin release for 0.6 would not be applied to the release for Forrest
>>0.5.
> If skin version 0.3 is compatible Forrest 0.5 and still works when 0.6 and 0.7
> are released, we could keep skinname-f0.5-0.3.jar The fetcher could get the
> skin with the highest forrest version number possible (less than or equal to the
> version of forrest installed, of course).
But we don't know still if they are compatible. Hence my subsequent
proposal that instead of f0.5 we use the *skin contract* version, that
is separate from the Forrest version. We should change it when the skins
have to change.
hence: skinname-0.2.jar where 0.2 is the *skin contract* version
In essence, what should happen is:
- if a skin is not present
- get the skins descriptor
- get the download dir of the skin
- get the current forrest skin version compat
(in the current Forrest)
- look for a file named skinname-skinversioncompat.zip
- if found
- download and unpack skin
- add a file with the date of the zip and the version
in the skin
- if not found
- search for skinname.zip (best effort skin)
- if found
(do as already specified above)
To update the skins, it does as above but downloads the skin only if the
remote file date is newer than the date that it wrote inside the skin.
In this way we don't need to generate and maintain descriptors in the
download dirs and in the zips, and have a simple naming scheme.
This is what I meant about Mozilla: the skins are downloadable per major
Mozilla version, not per skin version. In our case it would be per skin
version.
WDYT?
I hope I was clearer this time :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: multiple skin descriptors, skin versions
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Marshall Roch <ma...@exclupen.com>:
> Dave Brondsema wrote:
> >>IIRC I had added a filename convention too, so a skin would be for
> example:
> >>
> >> skinname-f0.5-0.3.jar (version 0.3 compatible with forrest 0.5)
> >
> > I like this. Simpler is better.
>
> I thought this was the problem. Skin version 0.3 might still work for
> Forrest 0.6 and 0.7, but with your proposed naming scheme, each skin
> would have to be re-released for each Forrest release, and bug fixes to
> the skin release for 0.6 would not be applied to the release for Forrest
> 0.5.
>
If skin version 0.3 is compatible Forrest 0.5 and still works when 0.6 and 0.7
are released, we could keep skinname-f0.5-0.3.jar The fetcher could get the
skin with the highest forrest version number possible (less than or equal to the
version of forrest installed, of course).
So the f0.5 would actually mean compatible with forrest 0.5 and greater. If
compatibility breaks at 0.8 (for example) then a skinname-f0.8-0.4.zip would
have to be made.
Would this work?
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - student org
Re: multiple skin descriptors, skin versions
Posted by Marshall Roch <ma...@exclupen.com>.
Dave Brondsema wrote:
>>IIRC I had added a filename convention too, so a skin would be for example:
>>
>> skinname-f0.5-0.3.jar (version 0.3 compatible with forrest 0.5)
>
> I like this. Simpler is better.
I thought this was the problem. Skin version 0.3 might still work for
Forrest 0.6 and 0.7, but with your proposed naming scheme, each skin
would have to be re-released for each Forrest release, and bug fixes to
the skin release for 0.6 would not be applied to the release for Forrest
0.5.
--
Marshall Roch
Re: multiple skin descriptors, skin versions
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting Nicola Ken Barozzi <ni...@apache.org>:
> Dave Brondsema wrote:
> ...
> > So each skin needs to declare what version it is and what versions of
> > forrest it is compatible with. We could put this in the skins.xml
> > along with the other info (url, name, etc) of the skin. However, the
> > version info needs to be self-contained in the skin and remain in a file
> > on the local installation of forrest. skins.xml files are temporary on
> > local installations.
>
> IIRC I had added a filename convention too, so a skin would be for example:
>
> skinname-f0.5-0.3.jar (version 0.3 compatible with forrest 0.5)
>
I like this. Simpler is better.
> But I still don't see why I would want an "old" skin for my Forrest (IE
> why get skinname-f0.5-0.2.jar if skinname-f0.5-0.3.jar is available?)
>
I agree.
> So, in the sake of simplicity, and following what happens with Mozilla
> skins, I propose that we define a skin version, and that this scheme is
> applied to the filenames of the skins just as it happens for Mozilla.
>
The file names of the themes don't seem to follow any pattern. Where do you see
this?
> To be able to update a skin, what I propose is to make the skin
> downloader add in the local unpacked skin the publish date if the skin
> on the site: in this way, in subsequent checks it can easily see if the
> skin has changed, and propose an update.
>
> WDYT?
>
Sounds good to me.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - student org
Re: multiple skin descriptors, skin versions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
...
> So each skin needs to declare what version it is and what versions of
> forrest it is compatible with. We could put this in the skins.xml
> along with the other info (url, name, etc) of the skin. However, the
> version info needs to be self-contained in the skin and remain in a file
> on the local installation of forrest. skins.xml files are temporary on
> local installations.
IIRC I had added a filename convention too, so a skin would be for example:
skinname-f0.5-0.3.jar (version 0.3 compatible with forrest 0.5)
But I still don't see why I would want an "old" skin for my Forrest (IE
why get skinname-f0.5-0.2.jar if skinname-f0.5-0.3.jar is available?)
> So I propose a skin.xml definition file to be in the base directory of
> each skin. It would contain the <skin> content from skinconf.xml in
> addition to version information. Skins.xml would just references these
> files (they would have to be available outside the .zip also for easy
> fetching).
Hmmm... a bit complicated for what we will be dealing with, that is some
skins. My skins webpage idea is something like this:
http://texturizer.net/firebird/themes/
I don't think we will be getting more skins than Mozilla ;-)
ATM the skin fetching, as you know, works by getting the skin that is
compatible with current Forrest (or at least it should be), by searching
for the filename that has the same number in the name.
As Marshall has shown, the Forrest version is not a true indicator of
the skin contract version.
On the other hand, I really don't see why one would want to download an
older version of a skin that works with his Forrest. (Note that if the
skin becomes different, it should change name, which BTW can also
contain numbers).
So, in the sake of simplicity, and following what happens with Mozilla
skins, I propose that we define a skin version, and that this scheme is
applied to the filenames of the skins just as it happens for Mozilla.
To be able to update a skin, what I propose is to make the skin
downloader add in the local unpacked skin the publish date if the skin
on the site: in this way, in subsequent checks it can easily see if the
skin has changed, and propose an update.
WDYT?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------