Re: Caching jx *without* flow
Leszek Gawron wrote: Thorsten Scherler wrote: Hi all, hi Ard, http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=2 ... Now, the cached jx would depend on these three parameters. Very easy to use, and less error prone than the flow part. If somebody is interested in the code I will hear Yes very interested. http://svn.apache.org/viewvc?view=revrev=446701 https://issues.apache.org/jira/browse/FOR-931 Can you attach a patch to this issue or commit it to cocoon directly? Would be awesome. Do I get it right: you want to patch JXTG to automatically build up a cache key from cocoon parameters? map:match pattern=foo map:generate src=foobar.jx map:parameter name=foo value=bar/ map:parameter name=bar value=foo/ /map:generate map:serialize/ /map:match so cocoon:/foo gets cached with something like foo=barbar=foo? Why need a patch for that? After all you already have jx:cache-key and jx:cache-validity. Since Ard is on holiday until the GetTogether, I'll try to answer this question. The reason is, as Ard said, to make it less error prone. People easily make mistakes if they have to build a cachekey string themselves, en they also easily forget to actually put the jx:cache-key and jx:cache-validity attributes in the JX template. I am talking from experience! It also makes the code more readable/transparent/explicit, because you don't need the extra flow step anymore in many cases. Regards, Niels
Re: Caching jx *without* flow
On Sun, 2006-09-17 at 13:48 +0200, Leszek Gawron wrote: Thorsten Scherler wrote: Hi all, hi Ard, http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=2 ... Now, the cached jx would depend on these three parameters. Very easy to use, and less error prone than the flow part. If somebody is interested in the code I will hear Yes very interested. http://svn.apache.org/viewvc?view=revrev=446701 https://issues.apache.org/jira/browse/FOR-931 Can you attach a patch to this issue or commit it to cocoon directly? Would be awesome. Do I get it right: you want to patch JXTG to automatically build up a cache key from cocoon parameters? map:match pattern=foo map:generate src=foobar.jx that is the normal file generator which is indeed cacheable. I am talking about map:generate type=jx src=foobar.jx which is not cacheable (if not changed since the last update of the cocoon in forrest). map:parameter name=foo value=bar/ map:parameter name=bar value=foo/ /map:generate map:serialize/ /map:match so cocoon:/foo gets cached with something like foo=barbar=foo? Why need a patch for that? After all you already have jx:cache-key and jx:cache-validity. Can you explain, I read the mail from Ard (see above marc link) and understood that one need to patch the jx generator to make it cacheable. If not can you give an example? TIA salu2 -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: Caching jx *without* flow
Niels van Kampenhout wrote:
Leszek Gawron wrote:
Thorsten Scherler wrote:
Hi all, hi Ard,
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=2
...
Now, the cached jx would depend on these three parameters.
Very easy to use, and less error prone than the flow part.
If somebody is interested in the code I will hear
Yes very interested.
http://svn.apache.org/viewvc?view=revrev=446701
https://issues.apache.org/jira/browse/FOR-931
Can you attach a patch to this issue or commit it to cocoon directly?
Would be awesome.
Do I get it right:
you want to patch JXTG to automatically build up a cache key from
cocoon parameters?
map:match pattern=foo
map:generate src=foobar.jx
map:parameter name=foo value=bar/
map:parameter name=bar value=foo/
/map:generate
map:serialize/
/map:match
so cocoon:/foo gets cached with something like foo=barbar=foo?
Why need a patch for that? After all you already have jx:cache-key and
jx:cache-validity.
Since Ard is on holiday until the GetTogether, I'll try to answer this
question.
The reason is, as Ard said, to make it less error prone. People easily
make mistakes if they have to build a cachekey string themselves, en
they also easily forget to actually put the jx:cache-key and
jx:cache-validity attributes in the JX template. I am talking from
experience!
It also makes the code more readable/transparent/explicit, because you
don't need the extra flow step anymore in many cases.
1. You don't need the extraflow step even right now. jx:cache-key and
jx:cache-validity works no matter what controller was used.
2. The solution you are proposing is error prone. The jx object model
does not get narrowed only to cocoon parameters so you are still able to
use cocoon.session, cocoon.request.
3. I hardly see the point to make any JXTG customizations if you can do
something like:
page
jx:cache-key=${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey(
cocoon.parameters )} jx:cache-validity=${some validity}
.../
/page
and
public class CocoonParametersCacheKeyBuilder {
public static String buildKey( Parameters parameters ) {
// you probably need to sort cocoon parameters here so the order is
// explicit
StringBuffer buffer = new StringBuffer();
String[] parameterNames = parameters.getNames();
for ( int i = 0; i parameterNames.length; ++i ) {
String currentParameterName = parameterNames[ i ];
if ( i 0 )
buffer.append( );
buffer.append( urlEncode( currentParameterName ) );
buffer.append( = );
buffer.append( urlEncode( parameters.getParameter(
currentParameterName ) ) );
}
return buffer.toString();
}
}
We could probably add this class to cocoon-template block and provide
some samples. Still - nothing needs to be changed.
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Caching jx *without* flow
On Mon, 2006-09-18 at 09:33 +0200, Niels van Kampenhout wrote: Leszek Gawron wrote: Thorsten Scherler wrote: Hi all, hi Ard, http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=2 ... Now, the cached jx would depend on these three parameters. Very easy to use, and less error prone than the flow part. If somebody is interested in the code I will hear Yes very interested. http://svn.apache.org/viewvc?view=revrev=446701 https://issues.apache.org/jira/browse/FOR-931 Can you attach a patch to this issue or commit it to cocoon directly? Would be awesome. Do I get it right: you want to patch JXTG to automatically build up a cache key from cocoon parameters? map:match pattern=foo map:generate src=foobar.jx map:parameter name=foo value=bar/ map:parameter name=bar value=foo/ /map:generate map:serialize/ /map:match so cocoon:/foo gets cached with something like foo=barbar=foo? Why need a patch for that? After all you already have jx:cache-key and jx:cache-validity. Since Ard is on holiday until the GetTogether, I'll try to answer this question. The reason is, as Ard said, to make it less error prone. People easily make mistakes if they have to build a cachekey string themselves, en they also easily forget to actually put the jx:cache-key and jx:cache-validity attributes in the JX template. I am talking from experience! Especially if one uses jx for pure presentation logic. The usecase in forrest is that we use jx for the structurers (which are part of the dispatcher). Meaning if we force the user to add above tags in the jx:template, we will spend our days in answering the user mails that forgot to add it or do not know how to do it, ... It also makes the code more readable/transparent/explicit, because you don't need the extra flow step anymore in many cases. Like stated in the subject, we do not even use flow and adding flow only for caching I consider kind of stupid. Can you give a hint how to do it? Is it as simple as adding the params to the cache key? If so would one use an aggregate validity since one would need to add all jx:import's to the validity object. I just wrapped up the caching in the dispatcher and I reckon the jx generator would need a similar patch like http://svn.apache.org/viewvc?view=revrevision=447311 (see DispatcherTransformer.java) http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherTransformer.java?r1=446701r2=447311pathrev=447311diff_format=h TIA salu2 Regards, Niels -- thorsten Together we stand, divided we fall! Hey you (Pink Floyd)
Re: Caching jx *without* flow
Thorsten Scherler wrote: map:match pattern=foo map:generate src=foobar.jx that is the normal file generator which is indeed cacheable. I am talking about map:generate type=jx src=foobar.jx which is not cacheable (if not changed since the last update of the cocoon in forrest). I am sorry - it should of course state map:generate type=jx src=foobar.jx JXTG IS cacheable if you provide jx:cache-key and jx:cache-validity in template body. map:parameter name=foo value=bar/ map:parameter name=bar value=foo/ /map:generate map:serialize/ /map:match so cocoon:/foo gets cached with something like foo=barbar=foo? Why need a patch for that? After all you already have jx:cache-key and jx:cache-validity. Can you explain, I read the mail from Ard (see above marc link) and understood that one need to patch the jx generator to make it cacheable. If not can you give an example? Please read my other reply. If I have time I will commit some samples to trunk that would outline jxtg caching. -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Caching jx *without* flow
Leszek Gawron wrote:
Niels van Kampenhout wrote:
Leszek Gawron wrote:
Thorsten Scherler wrote:
Hi all, hi Ard,
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=2
...
Now, the cached jx would depend on these three parameters.
Very easy to use, and less error prone than the flow part.
If somebody is interested in the code I will hear
Yes very interested.
http://svn.apache.org/viewvc?view=revrev=446701
https://issues.apache.org/jira/browse/FOR-931
Can you attach a patch to this issue or commit it to cocoon directly?
Would be awesome.
Do I get it right:
you want to patch JXTG to automatically build up a cache key from
cocoon parameters?
map:match pattern=foo
map:generate src=foobar.jx
map:parameter name=foo value=bar/
map:parameter name=bar value=foo/
/map:generate
map:serialize/
/map:match
so cocoon:/foo gets cached with something like foo=barbar=foo?
Why need a patch for that? After all you already have jx:cache-key
and jx:cache-validity.
Since Ard is on holiday until the GetTogether, I'll try to answer this
question.
The reason is, as Ard said, to make it less error prone. People easily
make mistakes if they have to build a cachekey string themselves, en
they also easily forget to actually put the jx:cache-key and
jx:cache-validity attributes in the JX template. I am talking from
experience!
It also makes the code more readable/transparent/explicit, because you
don't need the extra flow step anymore in many cases.
1. You don't need the extraflow step even right now. jx:cache-key and
jx:cache-validity works no matter what controller was used.
2. The solution you are proposing is error prone. The jx object model
does not get narrowed only to cocoon parameters so you are still able to
use cocoon.session, cocoon.request.
3. I hardly see the point to make any JXTG customizations if you can do
something like:
page
jx:cache-key=${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey(
cocoon.parameters )} jx:cache-validity=${some validity}
.../
/page
and
public class CocoonParametersCacheKeyBuilder {
public static String buildKey( Parameters parameters ) {
// you probably need to sort cocoon parameters here so the order is
// explicit
StringBuffer buffer = new StringBuffer();
String[] parameterNames = parameters.getNames();
for ( int i = 0; i parameterNames.length; ++i ) {
String currentParameterName = parameterNames[ i ];
if ( i 0 )
buffer.append( );
buffer.append( urlEncode( currentParameterName ) );
buffer.append( = );
buffer.append( urlEncode( parameters.getParameter(
currentParameterName ) ) );
}
return buffer.toString();
}
}
We could probably add this class to cocoon-template block and provide
some samples. Still - nothing needs to be changed.
I must admit that I don't know much about JXTG from a developer's
p.o.v., but from a user's p.o.v. (building web sites) our
HippoJXTemplateGenerator [1] has been a huge improvement over the JXTG.
But then, maybe JXTG has features that I don't know about which could
make life easier without the modifications in [1]. I can't find them in
the documentation [2,3] however. I guess I need to dive into the code
for that ;-)
Thanks,
Niels
[1]
http://svn.hippocms.org/repos/hippo/hippo-cocoon-extensions/trunk/hippo-misc/src/java/nl/hippo/cocoon/generation/HippoJXTemplateGenerator.java
[2] http://cocoon.apache.org/2.1/userdocs/jx-generator.html
[3] http://wiki.apache.org/cocoon/JXTemplateGenerator
Re: Caching jx *without* flow
On Mon, 2006-09-18 at 10:05 +0200, Leszek Gawron wrote:
Niels van Kampenhout wrote:
Leszek Gawron wrote:
Thorsten Scherler wrote:
Hi all, hi Ard,
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115194685214066w=2
...
Now, the cached jx would depend on these three parameters.
Very easy to use, and less error prone than the flow part.
If somebody is interested in the code I will hear
Yes very interested.
http://svn.apache.org/viewvc?view=revrev=446701
https://issues.apache.org/jira/browse/FOR-931
Can you attach a patch to this issue or commit it to cocoon directly?
Would be awesome.
Do I get it right:
you want to patch JXTG to automatically build up a cache key from
cocoon parameters?
map:match pattern=foo
map:generate src=foobar.jx
map:parameter name=foo value=bar/
map:parameter name=bar value=foo/
/map:generate
map:serialize/
/map:match
so cocoon:/foo gets cached with something like foo=barbar=foo?
Why need a patch for that? After all you already have jx:cache-key and
jx:cache-validity.
Since Ard is on holiday until the GetTogether, I'll try to answer this
question.
The reason is, as Ard said, to make it less error prone. People easily
make mistakes if they have to build a cachekey string themselves, en
they also easily forget to actually put the jx:cache-key and
jx:cache-validity attributes in the JX template. I am talking from
experience!
It also makes the code more readable/transparent/explicit, because you
don't need the extra flow step anymore in many cases.
1. You don't need the extraflow step even right now. jx:cache-key and
jx:cache-validity works no matter what controller was used.
2. The solution you are proposing is error prone. The jx object model
does not get narrowed only to cocoon parameters so you are still able to
use cocoon.session, cocoon.request.
Hmm, that is why Ard wrote:
now, to var ck you append the things that is depends on
(like a request parameter, current week number, etc)
Sure one need to take care to add all request parameter the jx depends on to
the sitemap.
I do not want to judge which method is more error prone, both have their pros
and cons.
3. I hardly see the point to make any JXTG customizations if you can do
something like:
page
jx:cache-key=${Packages.org.apache.cocoon.template.CocoonParametersCacheKeyBuilder.buildKey(
cocoon.parameters )} jx:cache-validity=${some validity}
.../
/page
and
public class CocoonParametersCacheKeyBuilder {
public static String buildKey( Parameters parameters ) {
// you probably need to sort cocoon parameters here so the order is
// explicit
StringBuffer buffer = new StringBuffer();
String[] parameterNames = parameters.getNames();
for ( int i = 0; i parameterNames.length; ++i ) {
String currentParameterName = parameterNames[ i ];
if ( i 0 )
buffer.append( );
buffer.append( urlEncode( currentParameterName ) );
buffer.append( = );
buffer.append( urlEncode( parameters.getParameter(
currentParameterName ) ) );
}
return buffer.toString();
}
}
Hmm, maybe the documentation is outdated but
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html state When
used inside flow, JXTemplate has access to Java and can therefore
evaluate expressions like java.util.Date() or java.util.HashMap().
This does NOT work when JXTemplates are used without flow.
Wouldn't that mean that the example would not work without flow?
Further regarding the validity as I understand your example this would
not allow to use an AggregatedValidity which would be extended for all
jx:import/, or?
Or could I do
jx:set var=validity value=new AggregatedValidity()/
...
jx:set var=validity value=${validity.add(importValidity)}
...
We could probably add this class to cocoon-template block and provide
some samples. Still - nothing needs to be changed.
Yeah that would be awesome. Still I am not sure whether the forrest
community would accept the inline solution. I understand your point
though, but under the user perspective I am with Niels.
salu2
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
Re: [M10N] Eclipse projects
Joerg Heinicke wrote: On 17.09.2006 14:38, Leszek Gawron wrote: Is this something we can influence at all? Is this a problem of the Maven Eclipse plugin? Or is everything left to the project wizard of Eclipse? Are you refering to maven eclipse plugin which you invoke by mvn eclipse:eclipse or to m2eclipse (which is an eclipse plugin for handling maven projects)? One is the Maven Eclipse plugin, the other one the Eclipse Maven plugin ;) I refer to Maven plugin invoked via eclipse:eclipse as described in our readme.txt or in Daisy. I've been having problems with this plugin too. Switched to m2eclipse. It is enough to refresh project after modifying pom.xml and new jars are automaticaly placed on classpath. -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [GT2006] 17 talks proposed!
Arje Cahn said the following on 15/9/06 14:35: I think this is really awsome list of talks. What do you think?? GREAT! +100 Things your mother never told you about Cocoon (The secret gems of Cocoon rebranded) +1 wednesdaymorning 10 Reasons to use Cocoon +1 wednesdaymorning Cocoon reloaded: moving from xsp and actions to newer technologies +1 for hackaton day 2 talk Case studies -1 (there's already a couple of them..) An illustrated guide to Cocoon technologies +1 (good fun to have in the morning sessions) Cocoon archetypes (How to create a typical project with cocoon rebranded) +0 I agree with all of these. I also agree with Betrand to have the rest of Andrew's talks be written up on XML.com or similar. We missed out on the last round of articles that I proposed after the previous GT, so it might as well get beyond the idea stage this time. Bye, Helma
Re: Caching jx *without* flow
Niels van Kampenhout wrote:
We could probably add this class to cocoon-template block and provide
some samples. Still - nothing needs to be changed.
I must admit that I don't know much about JXTG from a developer's
p.o.v., but from a user's p.o.v. (building web sites) our
HippoJXTemplateGenerator [1] has been a huge improvement over the JXTG.
But then, maybe JXTG has features that I don't know about which could
make life easier without the modifications in [1]. I can't find them in
the documentation [2,3] however. I guess I need to dive into the code
for that ;-)
Thanks,
Niels
[1]
http://svn.hippocms.org/repos/hippo/hippo-cocoon-extensions/trunk/hippo-misc/src/java/nl/hippo/cocoon/generation/HippoJXTemplateGenerator.java
[2] http://cocoon.apache.org/2.1/userdocs/jx-generator.html
[3] http://wiki.apache.org/cocoon/JXTemplateGenerator
Please update your cocoon checkout to the latest trunk. Then build
cocoon-webapp, run it and point your browser to:
http://localhost:/blocks/cocoon-template-sample/view/caching3
The template header is:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
jx:cache-key=${cocoon.request.parameters.toString()}
jx:cache-validity=${Packages.org.apache.excalibur.source.impl.validity.NOPValidity()}
you probably may do the same with
jx:cache-key=${cocoon.parameters.toString()} which will automatically
build up cache-key out of all cocoon parameters passed to the template.
Haven't tested it though. This means you probably don't even need any
additional code to achieve your goals.
The only thing that's missing from HippoJXTemplateGenerator.java
functionality is the ability to exclude some parameters from cache key.
Anyway this looks like FS from the start:
- if template makes use of all cocoon parameters they should be a part
of the cache key,
- if not - you shouldn't pass them instead of excluding.
Please comment.
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [GT2006] 17 talks proposed!
Hi, Arje Cahn wrote: I agree with all of these. I also agree with Betrand to have the rest of Andrew's talks be written up on XML.com or similar. We missed out on the last round of articles that I proposed after the previous GT, so it might as well get beyond the idea stage this time. ... Just a thought; what about hacking together an article at the hackaton with a couple of people?? I'd be happy to join! Andrew? WDYT? It all sounds good - and doing the article during the hackathon would be a great way to contribute for those of us (me included) that never manage to close bugs ;-) Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: Caching jx *without* flow
Leszek Gawron wrote:
Please update your cocoon checkout to the latest trunk. Then build
cocoon-webapp, run it and point your browser to:
http://localhost:/blocks/cocoon-template-sample/view/caching3
The template header is:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
jx:cache-key=${cocoon.request.parameters.toString()}
jx:cache-validity=${Packages.org.apache.excalibur.source.impl.validity.NOPValidity()}
you probably may do the same with
jx:cache-key=${cocoon.parameters.toString()} which will automatically
build up cache-key out of all cocoon parameters passed to the template.
Haven't tested it though. This means you probably don't even need any
additional code to achieve your goals.
I see what you mean, and I agree that it would allow us to do what we
are doing now with our custom code.
BTW, we use Cocoon 2.1.8, not the trunk.
The only thing that's missing from HippoJXTemplateGenerator.java
functionality is the ability to exclude some parameters from cache key.
Anyway this looks like FS from the start:
What do you mean by FS? False Security?
- if template makes use of all cocoon parameters they should be a part
of the cache key,
- if not - you shouldn't pass them instead of excluding.
Please comment.
These two statements are true, and exactly satisfy our requirements. You
may have other requirements, though.
What matters to me is this: in our projects we mainly use JXTG and XSLT,
and (as far as I can see from a user perspective) with our solution the
formation of the cache key is consistent between the two (cocoon
parameters == cache key). This is a big plus in the fragmented world of
Cocoon technologies.
Bottom line: we prefer different solutions and are both happy with them.
Good thing we live in a free world ;-)
Regards,
Niels
Re: Caching jx *without* flow
Niels van Kampenhout wrote:
Leszek Gawron wrote:
Please update your cocoon checkout to the latest trunk. Then build
cocoon-webapp, run it and point your browser to:
http://localhost:/blocks/cocoon-template-sample/view/caching3
The template header is:
page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
jx:cache-key=${cocoon.request.parameters.toString()}
jx:cache-validity=${Packages.org.apache.excalibur.source.impl.validity.NOPValidity()}
you probably may do the same with
jx:cache-key=${cocoon.parameters.toString()} which will
automatically build up cache-key out of all cocoon parameters passed
to the template. Haven't tested it though. This means you probably
don't even need any additional code to achieve your goals.
I see what you mean, and I agree that it would allow us to do what we
are doing now with our custom code.
BTW, we use Cocoon 2.1.8, not the trunk.
This should also work with 2.1
The only thing that's missing from HippoJXTemplateGenerator.java
functionality is the ability to exclude some parameters from cache
key. Anyway this looks like FS from the start:
What do you mean by FS? False Security?
Flexibility Syndrome :)
- if template makes use of all cocoon parameters they should be a part
of the cache key,
- if not - you shouldn't pass them instead of excluding.
Please comment.
These two statements are true, and exactly satisfy our requirements. You
may have other requirements, though.
I was refering to jx:includeKey and jx:excludeKey parameters in your
generator. Why do you use it at all?
What matters to me is this: in our projects we mainly use JXTG and XSLT,
and (as far as I can see from a user perspective) with our solution the
formation of the cache key is consistent between the two (cocoon
parameters == cache key). This is a big plus in the fragmented world of
Cocoon technologies.
I like the analogy. In order to fully utilise it we would have to go
further in similarities: JTGX object model in this case should be
constructed only with sitemap parameters.
automatic cache key from sitemap parameters + small object model = full
XSLT analogy. We could try this.
Bottom line: we prefer different solutions and are both happy with them.
Good thing we live in a free world ;-)
Agreed :)
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [GT2006] 17 talks proposed!
Andrew Savory said the following on 18/9/06 17:38: Hi, Arje Cahn wrote: I agree with all of these. I also agree with Betrand to have the rest of Andrew's talks be written up on XML.com or similar. We missed out on the last round of articles that I proposed after the previous GT, so it might as well get beyond the idea stage this time. ... Just a thought; what about hacking together an article at the hackaton with a couple of people?? I'd be happy to join! Andrew? WDYT? It all sounds good - and doing the article during the hackathon would be a great way to contribute for those of us (me included) that never manage to close bugs ;-) Great! I'll help out. Bye, Helma
