You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ivelin Ivanov <iv...@apache.org> on 2002/06/09 18:22:07 UTC
XInclude Transformer vs CInlude Transformer
Two almost identical transformers are confusing me.
What is the difference between the two?
Should one be deprecated?
I'd vote for the one which implements the W3C XInclude spec closest.
Maybe it should take the best of the other one.
--
-= Ivelin =-
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XInclude Transformer vs CInlude Transformer
Posted by Stefano Mazzocchi <st...@apache.org>.
Michael Wechner wrote:
> > For example, suppose you have something like this
> >
> > <blah>
> > <include xmlns="http://www.w3.org/xinclude/2000" src="blah.inc"/>
> > <include xmlns="http://apache.org/cocoon/include" src="blah.inc"/>
> > </blah>
>
> >
> > the first tag should *not* be processed by Cocoon, even by an
> > 'including' transformer.
>
> Please apologize if my question might be stupid, but what reason
> could there be not to process the first XInclude on the server, but
> to process the second on the server?
Performance and scalability. If we had client-side Xinclude, you could
have parts of your HTML pages xincluded and therefore cached, proxied
and so on, just like you do with images.
> I think it's very confusing if Cocoon would be using another namespace
> for XInclude than the one defined by w3.
In that case, you are forcing people *not* to be able to use xinclude on
client side and cocoon on the server side.
Sure, the need is not evident now that nobody implements xinclude on the
client side, but as soon as somebody does (and I think mozilla might the
first one), you'll see emerging needs for having client side *and*
server side inclusion.
Without different namespaces, this is simply not possible.
> If you want your example work as you describe it, then I think
> you can still do it the other way around, which means the initial
> XML would be as follows:
>
> <blah>
> <bi:include xmlns:bi="http://www.apache.org/cocoon/browserinclude"
> href="blah.xml"/>
> <xi:include xmlns="http://www.w3.org/2001/XInclude" href="blah.xml"/>
> </blah>
>
> then you send this XML through the XIncludeProcessorTransformer of
> Cocoon and receive something like
>
> <blah>
> <bi:include xmlns:bi="http://www.apache.org/cocoon/browserinclude"
> href="blah.xml"/>
> <blah>
> blabla
> </blah>
> </blah>
>
> then you send this XML through some XSLT (Transformer) which is
> replacing the bi:include by the xi:include
>
> <blah>
> <xi:include xmlns:bi="http://www.w3.org/2001/XInclude" href="blah.xml"/>
> <blah>
> blabla
> </blah>
> </blah>
>
> and then you send (serialize) it to the client.
>
> Or did I misunderstand your example?
No, this is correct, but you require a stylesheet to come up with
namespace rewriting (which is a hard thing to learn for users, in my
experience).
Having the ability to specify what namespace to react upon, is, IMO, a
better solution.
> >
> > So, IMO, the best long term solution would be:
> >
> > 1) deprecate both XIncludeTransformer and CIncludeTransformer
> > 2) change CIncludeTransformer to IncludeTransformer
> > 3) make IncludeTransformer work just on a cocoon-specific namespace
> >
> > what do you think?
>
> If you don't want to decide what namespaces, elementnames,
> attributenames you want to choose for the future, IMO it makes
> sense to make the IncludeTransformer configurable with the regard to
> the "names", such that it can process all types of "includes" as for
> instance <xsl:include, <xi:include, xlink:href, etc.
Yes, that makes sense.
> One Cocoon specific remark:
> I really learned to appreciate the "cocoon:" protocol supported by
> the current XIncludeTransformer. But it is a little bit "dangerous",
> because nobody else is supporting this protocol yet. In case you
> want to replace Cocoon by something else ;-) you will run into troubles
> because it won't work anymore. Therefore IMO it makes a lot of sense
> to use another namespace if you use the "cocoon:" protocol together
> with XInclude. But concerning the code base I think it makes a lot of
> sense to merge the code of the exsting ones.
I agree.
> I am currently refactoring my own XIncludeProcessor, and as soon
> as it is more "cocoonish" I will post it as a patch as Ivelin was
> suggesting it.
Cool, thanks.
> Maybe it helps someone.
>
> Thanks
>
> Michael
>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XInclude Transformer vs CInlude Transformer
Posted by Ivelin Ivanov <iv...@apache.org>.
Your solution sounds fine to me too.
Michael Wechner wrote:
>
>
> Stefano Mazzocchi wrote:
>
>> Mattam wrote:
>>
>>> Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]:
>>>
>>> |
>>> | Two almost identical transformers are confusing me.
>>> | What is the difference between the two?
>>> | Should one be deprecated?
>>> |
>>> | I'd vote for the one which implements the W3C XInclude spec closest.
>>> | Maybe it should take the best of the other one.
>>> |
>>>
>>> CInclude allows cocoon:/ protocol, and XInclude tends to be a strict
>>> implementation of the standard. Maybe keeping only XInclude while
>>> allowing the cocoon:/ protocol (with a switch?) would be the better.
>>>
>>
>> I agree, having both is highly confusing. Moreover, I think that we
>> should *not* be using the XInclude namespace on the server side because
>> we could get collisions in the future for browsers implementing XInclude
>> on the client side.
>>
>> For example, suppose you have something like this
>>
>> <blah>
>> <include xmlns="http://www.w3.org/xinclude/2000" src="blah.inc"/>
>> <include xmlns="http://apache.org/cocoon/include" src="blah.inc"/>
>> </blah>
>
>
>>
>> the first tag should *not* be processed by Cocoon, even by an
>> 'including' transformer.
>
>
>
>
> Please apologize if my question might be stupid, but what reason
> could there be not to process the first XInclude on the server, but
> to process the second on the server?
>
> I think it's very confusing if Cocoon would be using another namespace
> for XInclude than the one defined by w3.
>
> If you want your example work as you describe it, then I think
> you can still do it the other way around, which means the initial
> XML would be as follows:
>
> <blah>
> <bi:include xmlns:bi="http://www.apache.org/cocoon/browserinclude"
> href="blah.xml"/>
> <xi:include xmlns="http://www.w3.org/2001/XInclude" href="blah.xml"/>
> </blah>
>
> then you send this XML through the XIncludeProcessorTransformer of
> Cocoon and receive something like
>
> <blah>
> <bi:include xmlns:bi="http://www.apache.org/cocoon/browserinclude"
> href="blah.xml"/>
> <blah>
> blabla
> </blah>
> </blah>
>
> then you send this XML through some XSLT (Transformer) which is
> replacing the bi:include by the xi:include
>
> <blah>
> <xi:include xmlns:bi="http://www.w3.org/2001/XInclude" href="blah.xml"/>
> <blah>
> blabla
> </blah>
> </blah>
>
> and then you send (serialize) it to the client.
>
> Or did I misunderstand your example?
>
>
>>
>> So, IMO, the best long term solution would be:
>>
>> 1) deprecate both XIncludeTransformer and CIncludeTransformer
>> 2) change CIncludeTransformer to IncludeTransformer
>> 3) make IncludeTransformer work just on a cocoon-specific namespace
>>
>> what do you think?
>
>
>
> If you don't want to decide what namespaces, elementnames,
> attributenames you want to choose for the future, IMO it makes
> sense to make the IncludeTransformer configurable with the regard to
> the "names", such that it can process all types of "includes" as for
> instance <xsl:include, <xi:include, xlink:href, etc.
>
> One Cocoon specific remark:
> I really learned to appreciate the "cocoon:" protocol supported by
> the current XIncludeTransformer. But it is a little bit "dangerous",
> because nobody else is supporting this protocol yet. In case you
> want to replace Cocoon by something else ;-) you will run into troubles
> because it won't work anymore. Therefore IMO it makes a lot of sense
> to use another namespace if you use the "cocoon:" protocol together
> with XInclude. But concerning the code base I think it makes a lot of
> sense to merge the code of the exsting ones.
>
> I am currently refactoring my own XIncludeProcessor, and as soon
> as it is more "cocoonish" I will post it as a patch as Ivelin was
> suggesting it.
>
> Maybe it helps someone.
>
> Thanks
>
> Michael
>
>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
--
-= Ivelin =-
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XInclude Transformer vs CInlude Transformer
Posted by Michael Wechner <mi...@wyona.org>.
Stefano Mazzocchi wrote:
> Mattam wrote:
>
>>Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]:
>>
>>|
>>| Two almost identical transformers are confusing me.
>>| What is the difference between the two?
>>| Should one be deprecated?
>>|
>>| I'd vote for the one which implements the W3C XInclude spec closest.
>>| Maybe it should take the best of the other one.
>>|
>>
>>CInclude allows cocoon:/ protocol, and XInclude tends to be a strict implementation of the standard. Maybe keeping only XInclude while allowing the cocoon:/ protocol (with a switch?) would be the better.
>>
>
> I agree, having both is highly confusing. Moreover, I think that we
> should *not* be using the XInclude namespace on the server side because
> we could get collisions in the future for browsers implementing XInclude
> on the client side.
>
> For example, suppose you have something like this
>
> <blah>
> <include xmlns="http://www.w3.org/xinclude/2000" src="blah.inc"/>
> <include xmlns="http://apache.org/cocoon/include" src="blah.inc"/>
> </blah>
>
> the first tag should *not* be processed by Cocoon, even by an
> 'including' transformer.
Please apologize if my question might be stupid, but what reason
could there be not to process the first XInclude on the server, but
to process the second on the server?
I think it's very confusing if Cocoon would be using another namespace
for XInclude than the one defined by w3.
If you want your example work as you describe it, then I think
you can still do it the other way around, which means the initial
XML would be as follows:
<blah>
<bi:include xmlns:bi="http://www.apache.org/cocoon/browserinclude"
href="blah.xml"/>
<xi:include xmlns="http://www.w3.org/2001/XInclude" href="blah.xml"/>
</blah>
then you send this XML through the XIncludeProcessorTransformer of
Cocoon and receive something like
<blah>
<bi:include xmlns:bi="http://www.apache.org/cocoon/browserinclude"
href="blah.xml"/>
<blah>
blabla
</blah>
</blah>
then you send this XML through some XSLT (Transformer) which is
replacing the bi:include by the xi:include
<blah>
<xi:include xmlns:bi="http://www.w3.org/2001/XInclude" href="blah.xml"/>
<blah>
blabla
</blah>
</blah>
and then you send (serialize) it to the client.
Or did I misunderstand your example?
>
> So, IMO, the best long term solution would be:
>
> 1) deprecate both XIncludeTransformer and CIncludeTransformer
> 2) change CIncludeTransformer to IncludeTransformer
> 3) make IncludeTransformer work just on a cocoon-specific namespace
>
> what do you think?
If you don't want to decide what namespaces, elementnames,
attributenames you want to choose for the future, IMO it makes
sense to make the IncludeTransformer configurable with the regard to
the "names", such that it can process all types of "includes" as for
instance <xsl:include, <xi:include, xlink:href, etc.
One Cocoon specific remark:
I really learned to appreciate the "cocoon:" protocol supported by
the current XIncludeTransformer. But it is a little bit "dangerous",
because nobody else is supporting this protocol yet. In case you
want to replace Cocoon by something else ;-) you will run into troubles
because it won't work anymore. Therefore IMO it makes a lot of sense
to use another namespace if you use the "cocoon:" protocol together
with XInclude. But concerning the code base I think it makes a lot of
sense to merge the code of the exsting ones.
I am currently refactoring my own XIncludeProcessor, and as soon
as it is more "cocoonish" I will post it as a patch as Ivelin was
suggesting it.
Maybe it helps someone.
Thanks
Michael
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: XInclude Transformer vs CInlude Transformer
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Ivelin Ivanov [mailto:ivelin@apache.org]
>
> Stefano Mazzocchi wrote:
> > Mattam wrote:
...
> > So, IMO, the best long term solution would be:
> >
> > 1) deprecate both XIncludeTransformer and CIncludeTransformer
> > 2) change CIncludeTransformer to IncludeTransformer
> > 3) make IncludeTransformer work just on a cocoon-specific namespace
> >
> > what do you think?
>
>
> I think that we should leave XInclude transformer in.
> Many people think Cocoon is hard to learn. Having as many references
as
> possible to standards is essential.
>
> I would suggest that the XInclude transformer takes sitemap parameters
> which specify on which namespace to act. So if no parameters are
> provided it will act on "http://www.w3.org/xinclude/2000".
>
> Just like XSLT is useful on the server, XInclude is too.
> Although some browsers support XSLT and more will do so in future,
> XSLT on the server is valuable. The decision if transformation should
be
> applied or not belongs to the sitemap not the transformer.
> If XInclude should be left to the client, then the sitemap has to make
> sure that the XIclude transformer is either not applied at all, or at
> least not with the default namespace.
+1. Namespace should be configurable, and include transformer should
have all features of cinclude and xinclude.
Then, cinclude could be safely deprecated in favor of new xinclude.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XInclude Transformer vs CInlude Transformer
Posted by Ivelin Ivanov <iv...@apache.org>.
Stefano Mazzocchi wrote:
> Mattam wrote:
>
>>Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]:
>>
>>|
>>| Two almost identical transformers are confusing me.
>>| What is the difference between the two?
>>| Should one be deprecated?
>>|
>>| I'd vote for the one which implements the W3C XInclude spec closest.
>>| Maybe it should take the best of the other one.
>>|
>>
>>CInclude allows cocoon:/ protocol, and XInclude tends to be a strict implementation of the standard. Maybe keeping only XInclude while allowing the cocoon:/ protocol (with a switch?) would be the better.
>
>
> I agree, having both is highly confusing. Moreover, I think that we
> should *not* be using the XInclude namespace on the server side because
> we could get collisions in the future for browsers implementing XInclude
> on the client side.
>
> For example, suppose you have something like this
>
> <blah>
> <include xmlns="http://www.w3.org/xinclude/2000" src="blah.inc"/>
> <include xmlns="http://apache.org/cocoon/include" src="blah.inc"/>
> </blah>
>
> the first tag should *not* be processed by Cocoon, even by an
> 'including' transformer.
>
> So, IMO, the best long term solution would be:
>
> 1) deprecate both XIncludeTransformer and CIncludeTransformer
> 2) change CIncludeTransformer to IncludeTransformer
> 3) make IncludeTransformer work just on a cocoon-specific namespace
>
> what do you think?
I think that we should leave XInclude transformer in.
Many people think Cocoon is hard to learn. Having as many references as
possible to standards is essential.
I would suggest that the XInclude transformer takes sitemap parameters
which specify on which namespace to act. So if no parameters are
provided it will act on "http://www.w3.org/xinclude/2000".
Just like XSLT is useful on the server, XInclude is too.
Although some browsers support XSLT and more will do so in future,
XSLT on the server is valuable. The decision if transformation should be
applied or not belongs to the sitemap not the transformer.
If XInclude should be left to the client, then the sitemap has to make
sure that the XIclude transformer is either not applied at all, or at
least not with the default namespace.
>
--
-= Ivelin =-
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XInclude Transformer vs CInlude Transformer
Posted by Jeremy Quinn <sh...@mac.com>.
On Wednesday, June 12, 2002, at 09:10 PM, Stefano Mazzocchi wrote:
> So, IMO, the best long term solution would be:
>
> 1) deprecate both XIncludeTransformer and CIncludeTransformer
> 2) change CIncludeTransformer to IncludeTransformer
> 3) make IncludeTransformer work just on a cocoon-specific namespace
>
> what do you think?
>
+1
XInclude has useful stuff like:
parse="text|xml"
XPointer handling via '#' or xpointer() syntax
CInclude has useful stuff like:
element="wrapper"
ns="wrapper_ns"
prefix="wrapper_prefix"
It would be great to rationalise it all into one.
I completely agree with keeping a different namespace from w3c.XInclude.
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: XInclude Transformer vs CInlude Transformer
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> Mattam wrote:
> >
> > Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]:
> >
> > |
> > | Two almost identical transformers are confusing me.
> > | What is the difference between the two?
> > | Should one be deprecated?
> > |
> > | I'd vote for the one which implements the W3C XInclude spec closest.
> > | Maybe it should take the best of the other one.
> > |
> >
> > CInclude allows cocoon:/ protocol, and XInclude tends to be a
> strict implementation of the standard. Maybe keeping only
> XInclude while allowing the cocoon:/ protocol (with a switch?)
> would be the better.
>
> I agree, having both is highly confusing. Moreover, I think that we
> should *not* be using the XInclude namespace on the server side because
> we could get collisions in the future for browsers implementing XInclude
> on the client side.
>
In some cases this is true, but not in all. Imagine, fetching a distant
XML document containing xinclude commands. For processing it you need these
extra pieces of information, so you have to include the referenced documents
and therefore you need a xinclude transformer in some cases.
> For example, suppose you have something like this
>
> <blah>
> <include xmlns="http://www.w3.org/xinclude/2000" src="blah.inc"/>
> <include xmlns="http://apache.org/cocoon/include" src="blah.inc"/>
> </blah>
>
> the first tag should *not* be processed by Cocoon, even by an
> 'including' transformer.
>
> So, IMO, the best long term solution would be:
>
> 1) deprecate both XIncludeTransformer and CIncludeTransformer
> 2) change CIncludeTransformer to IncludeTransformer
> 3) make IncludeTransformer work just on a cocoon-specific namespace
>
> what do you think?
>
Again, I think XIncludeTransformer makes sense.
And we still have the third include transformer, the session transformer
which use is more verbose but therefore more flexible. Example:
<session:include xmlns:session="http://cocoon.apache.org/session/1.0">
<session:connection>
<session:target>http://www.xml.com/cocoon.xml</session:target>
<session:config>
<session:param>
<session:name>METHOD</session:name>
<session:value>POST</session:value>
</session:param>
</session:config>
<session:params>
<session:param>
<session:name>user</session:name>
<session:value>xyz</session:value>
</session:param>
</session:params>
</session:connection>
</session:include>
As you can see by this example, you can parameterize the connection (for
example
setting the HTTP method to POST) and you can simply add parameters (for
example
the user=xyz).
I admit that this is rather verbose, but it is very usefull, especially
setting
the method and the simple handling of additional parameters is a *must
have*.
So I would suggest that we deprecate the cincludetransforer and use the
above
functionality for a new include transformer (not necessarily the syntax and
names, but the functionality).
What do you think?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XInclude Transformer vs CInlude Transformer
Posted by Stefano Mazzocchi <st...@apache.org>.
Mattam wrote:
>
> Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]:
>
> |
> | Two almost identical transformers are confusing me.
> | What is the difference between the two?
> | Should one be deprecated?
> |
> | I'd vote for the one which implements the W3C XInclude spec closest.
> | Maybe it should take the best of the other one.
> |
>
> CInclude allows cocoon:/ protocol, and XInclude tends to be a strict implementation of the standard. Maybe keeping only XInclude while allowing the cocoon:/ protocol (with a switch?) would be the better.
I agree, having both is highly confusing. Moreover, I think that we
should *not* be using the XInclude namespace on the server side because
we could get collisions in the future for browsers implementing XInclude
on the client side.
For example, suppose you have something like this
<blah>
<include xmlns="http://www.w3.org/xinclude/2000" src="blah.inc"/>
<include xmlns="http://apache.org/cocoon/include" src="blah.inc"/>
</blah>
the first tag should *not* be processed by Cocoon, even by an
'including' transformer.
So, IMO, the best long term solution would be:
1) deprecate both XIncludeTransformer and CIncludeTransformer
2) change CIncludeTransformer to IncludeTransformer
3) make IncludeTransformer work just on a cocoon-specific namespace
what do you think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cachability (was RE: XInclude Transformer vs CInlude Transformer)
Posted by Conal Tuohy <co...@paradise.net.nz>.
Carsten wrote:
> Ok, first question: for what version are you planning to add
> the caching?
> If for 2.0.2/2.0.3 than the Cacheable interface is the right
> one, if you
> are planning it for 2.1 than CacheableProcesingComponent is
> the correct
> one.
Hmmm ... I haven't looked at 2.1 ... I think I will target that.
Thanks Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cachability (was RE: XInclude Transformer vs CInlude Transformer)
Posted by Per Kreipke <pe...@onclave.com>.
Carsten, Conal,
> > But actually my question is about caching of the DirectoryGenerator and
> > sub-classes. It seems to me that these transfomers should also be
> > cacheable;
> > maybe this is just an oversight too? Or is there something tricky
> > I haven't
> > forseen? ;-)
> AFAIK, the directory generator can be made cacheable as well, the
> only reason why it isn't is, that noone has done it yet, I think.
It depends on (as Carsten mentioned) the ability to detect that a
directory's contents have changed. Especially when diving down more than one
level using 'depth'.
Under Windows (don't kill me), I believe that directories are only modified
when the _list_ of files changes, not when a file is modified. In other
words, it's hard to detect that files' details have been modified without
getting those details, since you can't tell from the directory.
However, under Windows, there's a COM 'listener' API where you can register
a callback object to be notified when a directory or _any_ of its contents
are changed. Is there such an object/interface in Java? Perhaps in JDK 1.4?
Or, how about a COM wrapper object?
And that of course leaves Unix/Linux for which I have no idea.
<snip>
> > I could enhance it to only traverse PART of the file system
> again to check
> > the validity, by keeping a record of the file and directory
> > objects involved
> > in the last search. In the case of a directory search like
> "images/*.jpg",
> > or "docs/*.xml", the generator should only need to check the
> timestamp of
> > the "images" or "docs" directories, is that right? I've also
> used searches
> > like "images/{1}.jpg" with the ImageDirectoryGenerator, to get the image
> > width and height into a pipeline that converts the jpg to svg,
> > for scaling,
> > etc. In this case the validity could depend on the timestamp of
> > that single
> > file.
>
> Yes, collecting the files involved together with their last modification
> date is another possibility.
Without a 'listener' as described above, I'm not sure how this would
actually speed things up, you're still checking the lastModified date using
the File object.
That said, there are a couple of simple fixes to be made to the
ImageDirectoryGenerator and MP3DirectoryGenerator where caching will
significantly speed it up. I'll start a separate thread.
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Speedup *DirectoryGenerator (e.g. ImageDirectoryGenerator et
al)...
Posted by Steven Noels <st...@outerthought.org>.
Per Kreipke wrote:
> After looking at ImageDirectoryGenerator, which runs about 3x slower
> than DirectoryGenerator on image files, I think the following changes
> will speed it up (and similarily, MP3DirectoryGenerator).
Per,
we have just committed in Forrest CVS a pre-pre-version of a general
treewalking facility 'Libre' that can be packaged as a Cocoon generator
amongst others. It seems to me that you're trying to do more or less
what we have been doing (and which is 'ready' for refactoring anyhow ;-)
You can check this out at:
http://www.krysalis.org/forrest/libre-intro.html
http://cvs.apache.org/viewcvs.cgi/xml-forrest/src/scratchpad/src/java/
HTH,
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Speedup *DirectoryGenerator (e.g. ImageDirectoryGenerator et al)...
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Per Kreipke [mailto:per@onclave.com]
>
> > *DirectoryGenerators should be refactored so we have the only
> > DirectoryGenerator with pluggable 'processors' of different file
types.
> > This way, you will be able to generate listings of different files
of
> > type in one directory.
>
> That's a great idea but more grandiose. It certainly would be neat if
you
> could (use POI to) extract metadata from MS Office files, etc. I
imagine
> there are actually code libraries out there for all kinds of 'file
> introspection' or generating metadata from files.
>
> > > - having getSize() call getFileType() and then getJpegSize() or
> > > getGifSize(), introduces nice modularity but sacrifices speed.
Each
> > > function
> > > in that sequence calls (that's two calls total):
> > >
> > > new BufferedInputStream(new FileInputStream(file));
> > >
> > > Instead, instantiate the BufferedInputStream in getSize() and pass
it
> > > to the
> > > other functions. Or move the work from getFileType() and
get*Size()
> > > back in
> > > to getSize().
> >
> > Instantiate one instance of RandomAccessFile and pass it to
'processor'.
>
> Ok. This is re: the pluggable framework you mentioned above or does
this
> apply to the current code too?
MP3 needs it: TAG is in the tail... You don't want to read *all* file,
right? :)
> > > - more importantly, caching the information from getSize() plus
> > > 'lastModified' in an internal hash table with the file's URL as
key
> > > would
> > > remove the need to do the expensive work each time. If the file
hasn't
> > > changed, then it's size (or MP3 info) hasn't either.
> >
> > Cache key should be directory name plus settings, such as depth and
> > masks.
> >
> > Cache validity should be TimestampCacheValidity
(FileTimeStampValidity
> > in Cocoon 2.1) of all files selected by given depth/masks in this
> > directory.
>
> I think you missed my point, those suggestions apply to caching the
entire
> result, no?
Yes, that's to cache whole response.
> I'm not trying to cache the entire result for reasons listed in the
thread:
> "Cachability (was RE: XInclude Transformer vs CInlude Transformer".
I'm just
> trying to cache each file's metadata individually.
>
> E.g.:
>
> key (lastModified, width, height)
>
> d:\files\per\foo.jpeg: (123456789, 100, 50)
> d:\files\per\bar.gif: (987654321, 200, 100)
>
> Since the lastModified date is already computed by DirectoryGenerator,
it
> knows whether or not to dive into the file to re-get the metadata.
This is a
> precursor to your plug in architecture too: there's no reason to
re-get the
> info if the file hasn't been modified.
I see. Then, use Store. See XSLProcessor for example of component which
uses Store for its purposes.
> > > Unfortunately, I don't know Cocoon well enough to understand if
> > > Generators
> > > are global instances (so that all requests will share the hash
table)
> > > or
> > > whether it exists per pipeline, per sitemap, etc. My point: I'm
not
> > > sure how
> > > to implement the cached info correctly.
> >
> > Implement generateKey and generateValidity methods.
>
> Right, but that's only for caching the entire results.
Yup.
Vadim
> Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Sources, the next generation RE: Speedup *DirectoryGenerator
Posted by Marc Portier <mp...@outerthought.org>.
Stephen,
<snip part="introduction"/>
>
> One thing a want to prevent is, to get a one more 'DirectoryGenerator' or
> in your case a TreNavigationGenerator.
>
> So my idea was to have one generator and several implementations of
> SourceFactories. It makes also the life easier to get the access over
> different component.
>
+1
same idea here, I just guessed we do need at least _one_ more to traverse
the 'BrowsableSource' that in its getChildSources() calls upon the
SourceFactories to produce more to traverse? (and as said, hopefully with an
easy transformer incarnation)
>
> > > -----Original Message-----
> > > From: Stephan Michels [mailto:stephan@vern.chem.tu-berlin.de]
> > >
> > > On Fri, 14 Jun 2002, Per Kreipke wrote:
> > >
> > > > > *DirectoryGenerators should be refactored so we have the only
> > > > > DirectoryGenerator with pluggable 'processors' of different
> > > file types.
> > > > > This way, you will be able to generate listings of
> different files of
> > > > > type in one directory.
> > > >
> > > > That's a great idea but more grandiose. It certainly would be
> > > neat if you
> > > > could (use POI to) extract metadata from MS Office files,
> etc. I imagine
> > > > there are actually code libraries out there for all kinds of 'file
> > > > introspection' or generating metadata from files.
> > >
> > >
> > > At the moment I'm to evaluating way to get meta informations from
> > > repositories, like slide or over WebDAV. Also I want to be grant
> >
> > this thread adds up the number of sensible examples nicely
> > next to our focus on (1) filesystem with special xmlbased
> config file in it
> > (libre) there was just one other example: (2) a swing-like
> treeModel that
> > could be retrieved from a central place (and thus would be
> available to pure
> > swing clients as well)
> >
> > > permissions and locks to sources. My initial stage was creating
> > > 'SourceDescriptor', which is now in current CVS. But more I
> think about
> > > it as more I came to the conclusion that I should follow the SoC.
> > > The next idea is create some interfaces for 'Source' similar to
> > > 'WriteableSource'
> > >
> >
> > Haven't thought about it like this, but sure sounds great
> > One of the troubles I was neglecting to solve up to now was how to think
> > about hybrid trees of sources that would have child sources
> that would come
> > from a different implementation....
> >
> > If I understand this correctly (young but growing knowledge on
> cocoon and
> > avalon internals) there would be some kind of knowledge inside Avalon to
> > translate any source-URL into delivering an actual Source
> implementation?
>
> Yes, that is the way how it works.
>
cool, any particular part of the src distribution I can have a look into to
grasp this?
(or where you refering to 'this is how it _will_ work?' )
> > So there could then be a file:///..../dir, a
> dav://srv/path/collection , and
> > I would nead to think about some
> libre:///filelike-path/dir?cfg=libre.xml
> > (saying: look at this dir in the libre fasion by reading sort,
> filter and
> > attributing info from the libre.xml file you'll find there) don't see it
> > working for the images, mp3 case yet (list of file-extension to
> mimetype to
> > SourceImpl mappings??)
>
> There should be some kind of SourcePeropertyHelper, to get standard
> informations of different sources. Perhaps something like that
>
> <source-properties>
> <source-property extension="jpg"
> class="org.apache.cocoon.components.source.helper.ImageProperties"/>
> <source-property extension="mp3"
> class="org.apache.cocoon.components.source.helper.MP3Properties"/>
> </source-properties>
>
yep
I see these as the helper classes to read the availale properties
the ones that actually get into the output format should be more end-user
configurable I guess.
> > In which case each of them could say that one of their kids
> would in fact
> > exist outside their own implementation focus? (libre.xml could introduce
> > that with the <entry location="dav://..."> )
> >
> > (Currently I only thought about being able to switch the
> implementation at
> > the root level,in which case all descendants keep on living in the same
> > implementation space)
> >
> > In every case it would be nice if sourceURL of kids could be
> returned in a
> > relative manner?
> >
> > > So I have the following proposal:
> > >
> > > BrowsableSource:
> > >
> > > /** if the source a directory */
> > > boolean isCollection();
> > >
> > > /** Return the children of the collection */
> > > Enumeration getChildSources();
> > >
> > made a type-aware collection instead of the Enumeration
> > (which is one of my (bad?) habbits, it allows me to add some
> > browseEnumeration method that is taking an enumerationVisitor
> > interface implementation class with some acceptItem(theItem)
> > method... this kind of relieves the clients of some of the
> > casting and the boring hasNext() while loop, at the cost of
> > writing an anonymous inner class.)
>
> Yes, of cause, ther can be some kind of SourceList, SourcePropertyList.
>
> > also still in doubth on adding a hasChildSources() next to
> > the isCollection(), the subtle difference being:
> > - isCollection(): can you have kids?
> > - hasChildSources(): do you have any currently?
> > would be a way to get rid of empty <collection /> elms in the
> > generated output.
>
> Yes, a method hasChildSources is, I think, better.
>
just to be clear: my suggestion was adding it, not replacing it
your comment could be read either way
> > > InformalSource:
> > >
> > > /** To get a meta information from a source */
> > > SourceProperty getSourceProperty(String namespace, String name);
> > >
> > > /** To set a meta information */
> > > void setSourceProperty(SourceProperty property);
> > >
> > > /** Get alll informations */
> > > Enumeration getSourceProperties()
> > >
> > you mean getSourcePropertyNames() with the last one?
> > or do you expect a returned set of namespace-name-value
> > holding objects?
>
> The last one ;-)
>
yep
> > (is SourceProperty in alreay existing class maybe?)
> >
> > > RestrictableSource:
> > >
> > > /** Get a permission for a owner */
> > > SourcePermission getSourcePermission(String owner);
> > >
> > > /** Get a permission for the local owner */
> > > SourcePermission getSourcePermission();
> > >
> > > void setSourcePermission(SourcePermission permission);
> > >
> > > Enumeration getSourcePermissions();
> > >
> > > LockableSource:
> > >
> > > /** Get a lock for a owner */
> > > SourcePermission getSourceLock(String owner);
> > >
> > > /** Get a lock for the local owner */
> > > SourceLock getSourceLock();
> > >
> > > void setSourceLock(SourceLock lock);
> > >
> > > Enumeration getSourceLocks();
> > >
> >
> > the great thing about SoC is that I don't need to know what this is even
> > about :-)
> > (mapping dav stuff I persume)
> >
> > > The interface InformalSource could be used to get properties
> > > from a source, such like image width and height
> > >
> > > file://test.gif
> > > SourceProperty: namespace http://xml.apache.org/cocoon/source/image
> > > name width
> > > value 480
> > >
> > > The values should also contain XML fragment like
> > > SourceProperty: namespace http://www.test.org/mymetas
> > > name title
> > > value bla from <a>dgfdh</a>
> >
> > mmm, didn't do this either, in this case you're not thinking
> about setting
> > the property name-value as an attribute on the <item
> > ns-prefix:name="value"/> elm? but rather as a the content-model for the
> > generated output elm:
> > <item>
> > <ns-prefix:name>
> > <!-- whatever -->
> > </ns-prefix:name>
> > </item>
> >
> > how will you make the destincition between AttributeProperties and
> > NestedElementProperties?
>
> I don't. I want a similar syntax to PROPPATCH
>
> http://asg.web.cmu.edu/rfc/rfc2518.html#sec-8.1.1
>
you mean, in the output you would foresee a <prop> element that can have any
elements from other namespaces as it's contentmodel?
I was in fact referring to how you will programmatically decide what to do
with the propertyValue?
There is one getSourceProperties() in the InformalSource now, and we didn't
discuss the detail of the SourceProperty object... Question being: how will
the traverser know how to insert the propertyValue into the generated output
XML?
- as an attribute to the element OR
- as a nested element in the <prop> section of this element?
maybe this clarifies my latter remark as well:
> > In the latter case I'ld also try to avoid returning the
> property value as a
> > String, but rather hope for a mechanism to let the SourceImpl
> inject the SAX
> > Events directly to the output, or return at least use a
> > org.w3c.dom.DocumentFragment return type instead.
> >
giving the fact there is some SAX orientation my current feeling is there
could be need for asking first the Properties that have values to be
inserted in the atts-list, separate from asking the ones that need to end up
as nested elements.
> > >
> > > The next thing is that cocoon is able to browse through repositories
> > > At the moment DirectoryGenerator is limited to the file:// protocol, I
> > > think.
> > >
> > > I would also come to the point cachable. Source can IHMO implement
> > > recycable, to there is no need to retrieve all meta informations
> > > for every request.
> > >
> >
> > here, here, have been struggling on this one...
> > limited avalon understanding prevents me from seeing full
> solution though?
> >
> > > I had also took a look Ugo Cei's implementation of CocoBlog.
> He used RSS
> > > to create a description for every entry in xindice. I doesn't
> understand
> > > the difference between RSS and RDF. So I used for my first stage RDF.
> > > So my proposal is to write a 'SourceDescriptionGenerator'. It should
> > > work like DirectoyGenerator, catch all informations from a source, and
> > > generate a 'Resource Description'.
> > >
> > > One think, I doen't know to implement is associate 'SourceCredentials'
> > > to the source, such like username and password.
> > >
> > > Perhaps a ExtendedSourceFactory a possibility:
> > > ExtendedSourceFactory:
> > >
> > > Source getSource(SourceCredential credential, String location, Map
> > > parameters)
> > >
> > > So, what do you think, is this the right way?
> > >
> >
> > sorry, can't help you here yet...
> > hope I did in other parts.
> >
> > one more remark, while refactoring the DirectoryGenerator to
> > some TreeOfSourcesGenerator: design should not be thight to
> > a generatorImpl alone:
> > the use case for the transformer version is (avoiding the aggregation)
> > in a lot of cases the output of this thing will be used as some
> > right hand navigation of some webpage, but it can end up generating
> > small sub-trees just about anywhere I guess. In some cases people will
> > think about this more as a concern of the content-editor that would like
> > to write: <navigation-tree src="...." depth=".." /> to be picked up by
> > some TreeOfSourcesTransformer as well.
> > To achieve this I would separate the SAXgeneration stuff in some
> > TreeOfSourceReader to be used by both the traverser, and the generator.
> >
> > > Stephan Michels.
> > >
> > >
> > -marc=
regards,
-marc=
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Sources, the next generation RE: Speedup *DirectoryGenerator
Posted by Stephan Michels <st...@vern.chem.tu-berlin.de>.
On Sat, 15 Jun 2002, Marc Portier wrote:
> Hi Stephan,
>
> As Steven pointed out
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102412384403844&w=2) we've
> just started on something similar (so there is some momentum)
>
> in fact what you're talking about here maps to our package 'yer' which
> offers now some generic interfaces for defining (implementing) and
> traversing very generic hierarchical repositories... next to 'yer' the
> 'libre' thing is what allows us to add filtering, ordering and external
> attributing metadata to the classical filesystem (so the actual libre part
> in the code is probably only interesting inside the forrest context where we
> are trying to find a more flexible alternative to the book.xml for
> documentation stuff, the design around it could fit in with this nicely.)
>
> in every case I hope some of my recent experience on building this prototype
> can be of help, I took te liberty to add some comments inline...
One thing a want to prevent is, to get a one more 'DirectoryGenerator' or
in your case a TreNavigationGenerator.
So my idea was to have one generator and several implementations of
SourceFactories. It makes also the life easier to get the access over
different component.
> > -----Original Message-----
> > From: Stephan Michels [mailto:stephan@vern.chem.tu-berlin.de]
> >
> > On Fri, 14 Jun 2002, Per Kreipke wrote:
> >
> > > > *DirectoryGenerators should be refactored so we have the only
> > > > DirectoryGenerator with pluggable 'processors' of different
> > file types.
> > > > This way, you will be able to generate listings of different files of
> > > > type in one directory.
> > >
> > > That's a great idea but more grandiose. It certainly would be
> > neat if you
> > > could (use POI to) extract metadata from MS Office files, etc. I imagine
> > > there are actually code libraries out there for all kinds of 'file
> > > introspection' or generating metadata from files.
> >
> >
> > At the moment I'm to evaluating way to get meta informations from
> > repositories, like slide or over WebDAV. Also I want to be grant
>
> this thread adds up the number of sensible examples nicely
> next to our focus on (1) filesystem with special xmlbased config file in it
> (libre) there was just one other example: (2) a swing-like treeModel that
> could be retrieved from a central place (and thus would be available to pure
> swing clients as well)
>
> > permissions and locks to sources. My initial stage was creating
> > 'SourceDescriptor', which is now in current CVS. But more I think about
> > it as more I came to the conclusion that I should follow the SoC.
> > The next idea is create some interfaces for 'Source' similar to
> > 'WriteableSource'
> >
>
> Haven't thought about it like this, but sure sounds great
> One of the troubles I was neglecting to solve up to now was how to think
> about hybrid trees of sources that would have child sources that would come
> from a different implementation....
>
> If I understand this correctly (young but growing knowledge on cocoon and
> avalon internals) there would be some kind of knowledge inside Avalon to
> translate any source-URL into delivering an actual Source implementation?
Yes, that is the way how it works.
> So there could then be a file:///..../dir, a dav://srv/path/collection , and
> I would nead to think about some libre:///filelike-path/dir?cfg=libre.xml
> (saying: look at this dir in the libre fasion by reading sort, filter and
> attributing info from the libre.xml file you'll find there) don't see it
> working for the images, mp3 case yet (list of file-extension to mimetype to
> SourceImpl mappings??)
There should be some kind of SourcePeropertyHelper, to get standard
informations of different sources. Perhaps something like that
<source-properties>
<source-property extension="jpg"
class="org.apache.cocoon.components.source.helper.ImageProperties"/>
<source-property extension="mp3"
class="org.apache.cocoon.components.source.helper.MP3Properties"/>
</source-properties>
> In which case each of them could say that one of their kids would in fact
> exist outside their own implementation focus? (libre.xml could introduce
> that with the <entry location="dav://..."> )
>
> (Currently I only thought about being able to switch the implementation at
> the root level,in which case all descendants keep on living in the same
> implementation space)
>
> In every case it would be nice if sourceURL of kids could be returned in a
> relative manner?
>
> > So I have the following proposal:
> >
> > BrowsableSource:
> >
> > /** if the source a directory */
> > boolean isCollection();
> >
> > /** Return the children of the collection */
> > Enumeration getChildSources();
> >
> made a type-aware collection instead of the Enumeration
> (which is one of my (bad?) habbits, it allows me to add some
> browseEnumeration method that is taking an enumerationVisitor
> interface implementation class with some acceptItem(theItem)
> method... this kind of relieves the clients of some of the
> casting and the boring hasNext() while loop, at the cost of
> writing an anonymous inner class.)
Yes, of cause, ther can be some kind of SourceList, SourcePropertyList.
> also still in doubth on adding a hasChildSources() next to
> the isCollection(), the subtle difference being:
> - isCollection(): can you have kids?
> - hasChildSources(): do you have any currently?
> would be a way to get rid of empty <collection /> elms in the
> generated output.
Yes, a method hasChildSources is, I think, better.
> > InformalSource:
> >
> > /** To get a meta information from a source */
> > SourceProperty getSourceProperty(String namespace, String name);
> >
> > /** To set a meta information */
> > void setSourceProperty(SourceProperty property);
> >
> > /** Get alll informations */
> > Enumeration getSourceProperties()
> >
> you mean getSourcePropertyNames() with the last one?
> or do you expect a returned set of namespace-name-value
> holding objects?
The last one ;-)
> (is SourceProperty in alreay existing class maybe?)
>
> > RestrictableSource:
> >
> > /** Get a permission for a owner */
> > SourcePermission getSourcePermission(String owner);
> >
> > /** Get a permission for the local owner */
> > SourcePermission getSourcePermission();
> >
> > void setSourcePermission(SourcePermission permission);
> >
> > Enumeration getSourcePermissions();
> >
> > LockableSource:
> >
> > /** Get a lock for a owner */
> > SourcePermission getSourceLock(String owner);
> >
> > /** Get a lock for the local owner */
> > SourceLock getSourceLock();
> >
> > void setSourceLock(SourceLock lock);
> >
> > Enumeration getSourceLocks();
> >
>
> the great thing about SoC is that I don't need to know what this is even
> about :-)
> (mapping dav stuff I persume)
>
> > The interface InformalSource could be used to get properties
> > from a source, such like image width and height
> >
> > file://test.gif
> > SourceProperty: namespace http://xml.apache.org/cocoon/source/image
> > name width
> > value 480
> >
> > The values should also contain XML fragment like
> > SourceProperty: namespace http://www.test.org/mymetas
> > name title
> > value bla from <a>dgfdh</a>
>
> mmm, didn't do this either, in this case you're not thinking about setting
> the property name-value as an attribute on the <item
> ns-prefix:name="value"/> elm? but rather as a the content-model for the
> generated output elm:
> <item>
> <ns-prefix:name>
> <!-- whatever -->
> </ns-prefix:name>
> </item>
>
> how will you make the destincition between AttributeProperties and
> NestedElementProperties?
I don't. I want a similar syntax to PROPPATCH
http://asg.web.cmu.edu/rfc/rfc2518.html#sec-8.1.1
> In the latter case I'ld also try to avoid returning the property value as a
> String, but rather hope for a mechanism to let the SourceImpl inject the SAX
> Events directly to the output, or return at least use a
> org.w3c.dom.DocumentFragment return type instead.
>
> >
> > The next thing is that cocoon is able to browse through repositories
> > At the moment DirectoryGenerator is limited to the file:// protocol, I
> > think.
> >
> > I would also come to the point cachable. Source can IHMO implement
> > recycable, to there is no need to retrieve all meta informations
> > for every request.
> >
>
> here, here, have been struggling on this one...
> limited avalon understanding prevents me from seeing full solution though?
>
> > I had also took a look Ugo Cei's implementation of CocoBlog. He used RSS
> > to create a description for every entry in xindice. I doesn't understand
> > the difference between RSS and RDF. So I used for my first stage RDF.
> > So my proposal is to write a 'SourceDescriptionGenerator'. It should
> > work like DirectoyGenerator, catch all informations from a source, and
> > generate a 'Resource Description'.
> >
> > One think, I doen't know to implement is associate 'SourceCredentials'
> > to the source, such like username and password.
> >
> > Perhaps a ExtendedSourceFactory a possibility:
> > ExtendedSourceFactory:
> >
> > Source getSource(SourceCredential credential, String location, Map
> > parameters)
> >
> > So, what do you think, is this the right way?
> >
>
> sorry, can't help you here yet...
> hope I did in other parts.
>
> one more remark, while refactoring the DirectoryGenerator to
> some TreeOfSourcesGenerator: design should not be thight to
> a generatorImpl alone:
> the use case for the transformer version is (avoiding the aggregation)
> in a lot of cases the output of this thing will be used as some
> right hand navigation of some webpage, but it can end up generating
> small sub-trees just about anywhere I guess. In some cases people will
> think about this more as a concern of the content-editor that would like
> to write: <navigation-tree src="...." depth=".." /> to be picked up by
> some TreeOfSourcesTransformer as well.
> To achieve this I would separate the SAXgeneration stuff in some
> TreeOfSourceReader to be used by both the traverser, and the generator.
>
> > Stephan Michels.
> >
> >
> -marc=
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Sources, the next generation RE: Speedup *DirectoryGenerator
Posted by Marc Portier <mp...@outerthought.org>.
Hi Stephan,
As Steven pointed out
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102412384403844&w=2) we've
just started on something similar (so there is some momentum)
in fact what you're talking about here maps to our package 'yer' which
offers now some generic interfaces for defining (implementing) and
traversing very generic hierarchical repositories... next to 'yer' the
'libre' thing is what allows us to add filtering, ordering and external
attributing metadata to the classical filesystem (so the actual libre part
in the code is probably only interesting inside the forrest context where we
are trying to find a more flexible alternative to the book.xml for
documentation stuff, the design around it could fit in with this nicely.)
in every case I hope some of my recent experience on building this prototype
can be of help, I took te liberty to add some comments inline...
> -----Original Message-----
> From: Stephan Michels [mailto:stephan@vern.chem.tu-berlin.de]
>
> On Fri, 14 Jun 2002, Per Kreipke wrote:
>
> > > *DirectoryGenerators should be refactored so we have the only
> > > DirectoryGenerator with pluggable 'processors' of different
> file types.
> > > This way, you will be able to generate listings of different files of
> > > type in one directory.
> >
> > That's a great idea but more grandiose. It certainly would be
> neat if you
> > could (use POI to) extract metadata from MS Office files, etc. I imagine
> > there are actually code libraries out there for all kinds of 'file
> > introspection' or generating metadata from files.
>
>
> At the moment I'm to evaluating way to get meta informations from
> repositories, like slide or over WebDAV. Also I want to be grant
this thread adds up the number of sensible examples nicely
next to our focus on (1) filesystem with special xmlbased config file in it
(libre) there was just one other example: (2) a swing-like treeModel that
could be retrieved from a central place (and thus would be available to pure
swing clients as well)
> permissions and locks to sources. My initial stage was creating
> 'SourceDescriptor', which is now in current CVS. But more I think about
> it as more I came to the conclusion that I should follow the SoC.
> The next idea is create some interfaces for 'Source' similar to
> 'WriteableSource'
>
Haven't thought about it like this, but sure sounds great
One of the troubles I was neglecting to solve up to now was how to think
about hybrid trees of sources that would have child sources that would come
from a different implementation....
If I understand this correctly (young but growing knowledge on cocoon and
avalon internals) there would be some kind of knowledge inside Avalon to
translate any source-URL into delivering an actual Source implementation?
So there could then be a file:///..../dir, a dav://srv/path/collection , and
I would nead to think about some libre:///filelike-path/dir?cfg=libre.xml
(saying: look at this dir in the libre fasion by reading sort, filter and
attributing info from the libre.xml file you'll find there) don't see it
working for the images, mp3 case yet (list of file-extension to mimetype to
SourceImpl mappings??)
In which case each of them could say that one of their kids would in fact
exist outside their own implementation focus? (libre.xml could introduce
that with the <entry location="dav://..."> )
(Currently I only thought about being able to switch the implementation at
the root level,in which case all descendants keep on living in the same
implementation space)
In every case it would be nice if sourceURL of kids could be returned in a
relative manner?
> So I have the following proposal:
>
> BrowsableSource:
>
> /** if the source a directory */
> boolean isCollection();
>
> /** Return the children of the collection */
> Enumeration getChildSources();
>
made a type-aware collection instead of the Enumeration
(which is one of my (bad?) habbits, it allows me to add some
browseEnumeration method that is taking an enumerationVisitor
interface implementation class with some acceptItem(theItem)
method... this kind of relieves the clients of some of the
casting and the boring hasNext() while loop, at the cost of
writing an anonymous inner class.)
also still in doubth on adding a hasChildSources() next to
the isCollection(), the subtle difference being:
- isCollection(): can you have kids?
- hasChildSources(): do you have any currently?
would be a way to get rid of empty <collection /> elms in the
generated output.
> InformalSource:
>
> /** To get a meta information from a source */
> SourceProperty getSourceProperty(String namespace, String name);
>
> /** To set a meta information */
> void setSourceProperty(SourceProperty property);
>
> /** Get alll informations */
> Enumeration getSourceProperties()
>
you mean getSourcePropertyNames() with the last one?
or do you expect a returned set of namespace-name-value
holding objects?
(is SourceProperty in alreay existing class maybe?)
> RestrictableSource:
>
> /** Get a permission for a owner */
> SourcePermission getSourcePermission(String owner);
>
> /** Get a permission for the local owner */
> SourcePermission getSourcePermission();
>
> void setSourcePermission(SourcePermission permission);
>
> Enumeration getSourcePermissions();
>
> LockableSource:
>
> /** Get a lock for a owner */
> SourcePermission getSourceLock(String owner);
>
> /** Get a lock for the local owner */
> SourceLock getSourceLock();
>
> void setSourceLock(SourceLock lock);
>
> Enumeration getSourceLocks();
>
the great thing about SoC is that I don't need to know what this is even
about :-)
(mapping dav stuff I persume)
> The interface InformalSource could be used to get properties
> from a source, such like image width and height
>
> file://test.gif
> SourceProperty: namespace http://xml.apache.org/cocoon/source/image
> name width
> value 480
>
> The values should also contain XML fragment like
> SourceProperty: namespace http://www.test.org/mymetas
> name title
> value bla from <a>dgfdh</a>
mmm, didn't do this either, in this case you're not thinking about setting
the property name-value as an attribute on the <item
ns-prefix:name="value"/> elm? but rather as a the content-model for the
generated output elm:
<item>
<ns-prefix:name>
<!-- whatever -->
</ns-prefix:name>
</item>
how will you make the destincition between AttributeProperties and
NestedElementProperties?
In the latter case I'ld also try to avoid returning the property value as a
String, but rather hope for a mechanism to let the SourceImpl inject the SAX
Events directly to the output, or return at least use a
org.w3c.dom.DocumentFragment return type instead.
>
> The next thing is that cocoon is able to browse through repositories
> At the moment DirectoryGenerator is limited to the file:// protocol, I
> think.
>
> I would also come to the point cachable. Source can IHMO implement
> recycable, to there is no need to retrieve all meta informations
> for every request.
>
here, here, have been struggling on this one...
limited avalon understanding prevents me from seeing full solution though?
> I had also took a look Ugo Cei's implementation of CocoBlog. He used RSS
> to create a description for every entry in xindice. I doesn't understand
> the difference between RSS and RDF. So I used for my first stage RDF.
> So my proposal is to write a 'SourceDescriptionGenerator'. It should
> work like DirectoyGenerator, catch all informations from a source, and
> generate a 'Resource Description'.
>
> One think, I doen't know to implement is associate 'SourceCredentials'
> to the source, such like username and password.
>
> Perhaps a ExtendedSourceFactory a possibility:
> ExtendedSourceFactory:
>
> Source getSource(SourceCredential credential, String location, Map
> parameters)
>
> So, what do you think, is this the right way?
>
sorry, can't help you here yet...
hope I did in other parts.
one more remark, while refactoring the DirectoryGenerator to
some TreeOfSourcesGenerator: design should not be thight to
a generatorImpl alone:
the use case for the transformer version is (avoiding the aggregation)
in a lot of cases the output of this thing will be used as some
right hand navigation of some webpage, but it can end up generating
small sub-trees just about anywhere I guess. In some cases people will
think about this more as a concern of the content-editor that would like
to write: <navigation-tree src="...." depth=".." /> to be picked up by
some TreeOfSourcesTransformer as well.
To achieve this I would separate the SAXgeneration stuff in some
TreeOfSourceReader to be used by both the traverser, and the generator.
> Stephan Michels.
>
>
-marc=
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[PROPOSAL] Sources, the next generation RE: Speedup *DirectoryGenerator
Posted by Stephan Michels <st...@vern.chem.tu-berlin.de>.
On Fri, 14 Jun 2002, Per Kreipke wrote:
> > *DirectoryGenerators should be refactored so we have the only
> > DirectoryGenerator with pluggable 'processors' of different file types.
> > This way, you will be able to generate listings of different files of
> > type in one directory.
>
> That's a great idea but more grandiose. It certainly would be neat if you
> could (use POI to) extract metadata from MS Office files, etc. I imagine
> there are actually code libraries out there for all kinds of 'file
> introspection' or generating metadata from files.
At the moment I'm to evaluating way to get meta informations from
repositories, like slide or over WebDAV. Also I want to be grant
permissions and locks to sources. My initial stage was creating
'SourceDescriptor', which is now in current CVS. But more I think about
it as more I came to the conclusion that I should follow the SoC.
The next idea is create some interfaces for 'Source' similar to
'WriteableSource'
So I have the following proposal:
BrowsableSource:
/** if the source a directory */
boolean isCollection();
/** Return the children of the collection */
Enumeration getChildSources();
InformalSource:
/** To get a meta information from a source */
SourceProperty getSourceProperty(String namespace, String name);
/** To set a meta information */
void setSourceProperty(SourceProperty property);
/** Get alll informations */
Enumeration getSourceProperties()
RestrictableSource:
/** Get a permission for a owner */
SourcePermission getSourcePermission(String owner);
/** Get a permission for the local owner */
SourcePermission getSourcePermission();
void setSourcePermission(SourcePermission permission);
Enumeration getSourcePermissions();
LockableSource:
/** Get a lock for a owner */
SourcePermission getSourceLock(String owner);
/** Get a lock for the local owner */
SourceLock getSourceLock();
void setSourceLock(SourceLock lock);
Enumeration getSourceLocks();
The interface InformalSource could be used to get properties
from a source, such like image width and height
file://test.gif
SourceProperty: namespace http://xml.apache.org/cocoon/source/image
name width
value 480
The values should also contain XML fragment like
SourceProperty: namespace http://www.test.org/mymetas
name title
value bla from <a>dgfdh</a>
The next thing is that cocoon is able to browse through repositories
At the moment DirectoryGenerator is limited to the file:// protocol, I
think.
I would also come to the point cachable. Source can IHMO implement
recycable, to there is no need to retrieve all meta informations
for every request.
I had also took a look Ugo Cei's implementation of CocoBlog. He used RSS
to create a description for every entry in xindice. I doesn't understand
the difference between RSS and RDF. So I used for my first stage RDF.
So my proposal is to write a 'SourceDescriptionGenerator'. It should
work like DirectoyGenerator, catch all informations from a source, and
generate a 'Resource Description'.
One think, I doen't know to implement is associate 'SourceCredentials'
to the source, such like username and password.
Perhaps a ExtendedSourceFactory a possibility:
ExtendedSourceFactory:
Source getSource(SourceCredential credential, String location, Map
parameters)
So, what do you think, is this the right way?
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Speedup *DirectoryGenerator (e.g. ImageDirectoryGenerator et al)...
Posted by Per Kreipke <pe...@onclave.com>.
> *DirectoryGenerators should be refactored so we have the only
> DirectoryGenerator with pluggable 'processors' of different file types.
> This way, you will be able to generate listings of different files of
> type in one directory.
That's a great idea but more grandiose. It certainly would be neat if you
could (use POI to) extract metadata from MS Office files, etc. I imagine
there are actually code libraries out there for all kinds of 'file
introspection' or generating metadata from files.
> > - having getSize() call getFileType() and then getJpegSize() or
> > getGifSize(), introduces nice modularity but sacrifices speed. Each
> function
> > in that sequence calls (that's two calls total):
> >
> > new BufferedInputStream(new FileInputStream(file));
> >
> > Instead, instantiate the BufferedInputStream in getSize() and pass it
> to the
> > other functions. Or move the work from getFileType() and get*Size()
> back in
> > to getSize().
>
> Instantiate one instance of RandomAccessFile and pass it to 'processor'.
Ok. This is re: the pluggable framework you mentioned above or does this
apply to the current code too?
> > - more importantly, caching the information from getSize() plus
> > 'lastModified' in an internal hash table with the file's URL as key
> would
> > remove the need to do the expensive work each time. If the file hasn't
> > changed, then it's size (or MP3 info) hasn't either.
>
> Cache key should be directory name plus settings, such as depth and
> masks.
>
> Cache validity should be TimestampCacheValidity (FileTimeStampValidity
> in Cocoon 2.1) of all files selected by given depth/masks in this
> directory.
I think you missed my point, those suggestions apply to caching the entire
result, no?
I'm not trying to cache the entire result for reasons listed in the thread:
"Cachability (was RE: XInclude Transformer vs CInlude Transformer". I'm just
trying to cache each file's metadata individually.
E.g.:
key (lastModified, width, height)
d:\files\per\foo.jpeg: (123456789, 100, 50)
d:\files\per\bar.gif: (987654321, 200, 100)
Since the lastModified date is already computed by DirectoryGenerator, it
knows whether or not to dive into the file to re-get the metadata. This is a
precursor to your plug in architecture too: there's no reason to re-get the
info if the file hasn't been modified.
> > Unfortunately, I don't know Cocoon well enough to understand if
> Generators
> > are global instances (so that all requests will share the hash table)
> or
> > whether it exists per pipeline, per sitemap, etc. My point: I'm not
> sure how
> > to implement the cached info correctly.
>
> Implement generateKey and generateValidity methods.
Right, but that's only for caching the entire results.
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Speedup *DirectoryGenerator (e.g. ImageDirectoryGenerator et al)...
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Per Kreipke [mailto:per@onclave.com]
...
> Wouldn't it be nice if the second time you requested the image info,
it was
> as fast as the DirectoryGenerator?
>
>
> Suggestions:
*DirectoryGenerators should be refactored so we have the only
DirectoryGenerator with pluggable 'processors' of different file types.
This way, you will be able to generate listings of different files of
type in one directory.
> - having getSize() call getFileType() and then getJpegSize() or
> getGifSize(), introduces nice modularity but sacrifices speed. Each
function
> in that sequence calls (that's two calls total):
>
> new BufferedInputStream(new FileInputStream(file));
>
> Instead, instantiate the BufferedInputStream in getSize() and pass it
to the
> other functions. Or move the work from getFileType() and get*Size()
back in
> to getSize().
Instantiate one instance of RandomAccessFile and pass it to 'processor'.
> - more importantly, caching the information from getSize() plus
> 'lastModified' in an internal hash table with the file's URL as key
would
> remove the need to do the expensive work each time. If the file hasn't
> changed, then it's size (or MP3 info) hasn't either.
Cache key should be directory name plus settings, such as depth and
masks.
Cache validity should be TimestampCacheValidity (FileTimeStampValidity
in Cocoon 2.1) of all files selected by given depth/masks in this
directory.
> Unfortunately, I don't know Cocoon well enough to understand if
Generators
> are global instances (so that all requests will share the hash table)
or
> whether it exists per pipeline, per sitemap, etc. My point: I'm not
sure how
> to implement the cached info correctly.
Implement generateKey and generateValidity methods.
Vadim
> I would love to do this work and send in the patch myself, and I'll
attempt
> to do so when I have the latest C2 source installed here. Unless
someone
> desparate does it first :-)
>
> Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Speedup *DirectoryGenerator (e.g. ImageDirectoryGenerator et al)...
Posted by Per Kreipke <pe...@onclave.com>.
After looking at ImageDirectoryGenerator, which runs about 3x slower than
DirectoryGenerator on image files, I think the following changes will speed
it up (and similarily, MP3DirectoryGenerator).
For fun, compare DirectoryGenerator against ImageDirectoryGenerator on the
same directory (with a moderate number of images:
<map:match pattern="files/*">
<map:generator type="DirectoryGenerator" >
<map:parameter name="depth" value="3" />
</map:generator>
<map:serialize type="xml" />
</map:match>
<map:match pattern="files2/*">
<map:generator type="ImageDirectoryGenerator" >
<map:parameter name="depth" value="3" />
</map:generator>
<map:serialize type="xml" />
</map:match>
Wouldn't it be nice if the second time you requested the image info, it was
as fast as the DirectoryGenerator?
Suggestions:
- having getSize() call getFileType() and then getJpegSize() or
getGifSize(), introduces nice modularity but sacrifices speed. Each function
in that sequence calls (that's two calls total):
new BufferedInputStream(new FileInputStream(file));
Instead, instantiate the BufferedInputStream in getSize() and pass it to the
other functions. Or move the work from getFileType() and get*Size() back in
to getSize().
- more importantly, caching the information from getSize() plus
'lastModified' in an internal hash table with the file's URL as key would
remove the need to do the expensive work each time. If the file hasn't
changed, then it's size (or MP3 info) hasn't either.
Unfortunately, I don't know Cocoon well enough to understand if Generators
are global instances (so that all requests will share the hash table) or
whether it exists per pipeline, per sitemap, etc. My point: I'm not sure how
to implement the cached info correctly.
I would love to do this work and send in the patch myself, and I'll attempt
to do so when I have the latest C2 source installed here. Unless someone
desparate does it first :-)
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Cachability (was RE: XInclude Transformer vs CInlude Transformer)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Conal Tuohy wrote:
>
> I've just been looking at "inclusion" recently and noticed that
> the cinclude
> transformer had caching but the xinclude transformer didn't, and
> I wondered
> if there was some arcane reason or was it just a historial
> accident ;-) And
> BTW I think Carsten is right - the inclusion code should be united.
>
Thanks :)
> But actually my question is about caching of the DirectoryGenerator and
> sub-classes. It seems to me that these transfomers should also be
> cacheable;
> maybe this is just an oversight too? Or is there something tricky
> I haven't
> forseen? ;-)
AFAIK, the directory generator can be made cacheable as well, the
only reason why it isn't is, that noone has done it yet, I think.
>
> I have a pipeline based on a directory listing of xml docs; with
> 9 documents
> it takes 2 or 3 seconds to complete - and with 100 docs it will be
> impossible. But the files aren't often changed.
>
> Anyway, I thought I might make an attempt at adding caching to the
> DirectoryGenerator. It seems to me that the generator could perform the
> search and traverse the file system every time a request is made, but hash
> the resulting xml for the CacheValidity. Is that right? This would be my
> first attempt.
Ok, first question: for what version are you planning to add the caching?
If for 2.0.2/2.0.3 than the Cacheable interface is the right one, if you
are planning it for 2.1 than CacheableProcesingComponent is the correct
one.
Both interfaces are similar regarding their functions but not their return
values. A cacheable component returns a unique key. For the directory
generator this could be the full path of the directory together with the
settings
(include pattern, exclude pattern etc).
Second, a CacheValidity (Cacheable) or a SourceValidity
(CacheableProcesingComponent)
object is returned which is used to detect if the source (= directory)
of the generator changed. So if you use, e.g. the last modificiation
date of the directory here, this should work. (If the last modification date
of the directory changes, if a file changes inside the directory)
>
> I could enhance it to only traverse PART of the file system again to check
> the validity, by keeping a record of the file and directory
> objects involved
> in the last search. In the case of a directory search like "images/*.jpg",
> or "docs/*.xml", the generator should only need to check the timestamp of
> the "images" or "docs" directories, is that right? I've also used searches
> like "images/{1}.jpg" with the ImageDirectoryGenerator, to get the image
> width and height into a pipeline that converts the jpg to svg,
> for scaling,
> etc. In this case the validity could depend on the timestamp of
> that single
> file.
Yes, collecting the files involved together with their last modification
date is another possibility.
HTH
Carsten
Carsten Ziegeler Chief Architect Open Source Group, S&N AG
------------------------------------------------------------------
Cocoon Consulting, Training and Projects
------------------------------------------------------------------
mailto:cziegeler@s-und-n.de http://www.s-und-n.de
http://ziegeler.bei.t-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Cachability (was RE: XInclude Transformer vs CInlude Transformer)
Posted by Conal Tuohy <co...@paradise.net.nz>.
I've just been looking at "inclusion" recently and noticed that the cinclude
transformer had caching but the xinclude transformer didn't, and I wondered
if there was some arcane reason or was it just a historial accident ;-) And
BTW I think Carsten is right - the inclusion code should be united.
But actually my question is about caching of the DirectoryGenerator and
sub-classes. It seems to me that these transfomers should also be cacheable;
maybe this is just an oversight too? Or is there something tricky I haven't
forseen? ;-)
I have a pipeline based on a directory listing of xml docs; with 9 documents
it takes 2 or 3 seconds to complete - and with 100 docs it will be
impossible. But the files aren't often changed.
Anyway, I thought I might make an attempt at adding caching to the
DirectoryGenerator. It seems to me that the generator could perform the
search and traverse the file system every time a request is made, but hash
the resulting xml for the CacheValidity. Is that right? This would be my
first attempt.
I could enhance it to only traverse PART of the file system again to check
the validity, by keeping a record of the file and directory objects involved
in the last search. In the case of a directory search like "images/*.jpg",
or "docs/*.xml", the generator should only need to check the timestamp of
the "images" or "docs" directories, is that right? I've also used searches
like "images/{1}.jpg" with the ImageDirectoryGenerator, to get the image
width and height into a pipeline that converts the jpg to svg, for scaling,
etc. In this case the validity could depend on the timestamp of that single
file.
Any hints or comments would be much appreciated!
Con
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> Sent: Wednesday, 12 June 2002 19:03
> To: cocoon-dev@xml.apache.org
> Subject: RE: XInclude Transformer vs CInlude Transformer
>
>
>
> >
> > Carsten? Donald? Why we have two transformers?
> > :)
> >
> I don't remember the exact reason, but I think Stefano brought this up
> originally.
> The xinclude transformer implements the xinclude spec, but
> the cinclude
> transformer was invented to bring an easier and more
> intuitive notation for
> including documents. I quickly searched through the mail
> archive but didn't
> find the original mails...
>
> To be more precisly, we have three transformers doing the
> job! The session
> transformer also has an include concept which is more
> detailed than xinclude
> and cinclude as it can also do POST operations, pass parameters etc.
>
> I personally don't see a real problem in having different
> notations for the
> same job, but perhaps we can make one code bass out of it,
> let's say an
> include transformer doing xinclude, cinclude and the include
> job of the
> session transformer.
>
> Carsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: XInclude Transformer vs CInlude Transformer
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
>
> Carsten? Donald? Why we have two transformers?
> :)
>
I don't remember the exact reason, but I think Stefano brought this up
originally.
The xinclude transformer implements the xinclude spec, but the cinclude
transformer was invented to bring an easier and more intuitive notation for
including documents. I quickly searched through the mail archive but didn't
find the original mails...
To be more precisly, we have three transformers doing the job! The session
transformer also has an include concept which is more detailed than xinclude
and cinclude as it can also do POST operations, pass parameters etc.
I personally don't see a real problem in having different notations for the
same job, but perhaps we can make one code bass out of it, let's say an
include transformer doing xinclude, cinclude and the include job of the
session transformer.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: XInclude Transformer vs CInlude Transformer
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Ivelin Ivanov [mailto:ivelin@apache.org]
>
> Vadim Gritsenko wrote:
> >>From: Mattam [mailto:mattam@netcourrier.com]
> >>
> >>Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]:
> >>
> >>|
> >>| Two almost identical transformers are confusing me.
> >>| What is the difference between the two?
> >>| Should one be deprecated?
> >>|
> >>| I'd vote for the one which implements the W3C XInclude spec
closest.
> >>| Maybe it should take the best of the other one.
> >>|
> >>
> >>CInclude allows cocoon:/ protocol, and XInclude tends to be a strict
> >>implementation of the standard. Maybe keeping only XInclude while
> >
> > allowing the
> >
> >>cocoon:/ protocol (with a switch?) would be the better.
> >
> >
> > That's not right; XInclude also works with cocoon: protocol, they
both
> > use Cocoon's resolver.
> >
> > IIRC, the reason of CInclude existence is completely different: if
you
> > remove CInclude, it will be more complicated to serve documents with
> > inclusions and with tags in xinclude namespace. Right now, this is
not
> > an issue: create document with xinclude *and* cinclude tags, process
it
> > through cinclude, and xinclude will remain intact, no sweat.
>
>
> Does this justify a separate code base though? Allowing the Xinclude
> component to act on a sitemap parameter specified namespace should do.
Carsten? Donald? Why we have two transformers?
:)
If xinclude gets caching ability (as CachingCIncludeTransformer does), I
say one transformer should suffice.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XInclude Transformer vs CInlude Transformer
Posted by Ivelin Ivanov <iv...@apache.org>.
Vadim Gritsenko wrote:
>>From: Mattam [mailto:mattam@netcourrier.com]
>>
>>Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]:
>>
>>|
>>| Two almost identical transformers are confusing me.
>>| What is the difference between the two?
>>| Should one be deprecated?
>>|
>>| I'd vote for the one which implements the W3C XInclude spec closest.
>>| Maybe it should take the best of the other one.
>>|
>>
>>CInclude allows cocoon:/ protocol, and XInclude tends to be a strict
>>implementation of the standard. Maybe keeping only XInclude while
>
> allowing the
>
>>cocoon:/ protocol (with a switch?) would be the better.
>
>
> That's not right; XInclude also works with cocoon: protocol, they both
> use Cocoon's resolver.
>
> IIRC, the reason of CInclude existence is completely different: if you
> remove CInclude, it will be more complicated to serve documents with
> inclusions and with tags in xinclude namespace. Right now, this is not
> an issue: create document with xinclude *and* cinclude tags, process it
> through cinclude, and xinclude will remain intact, no sweat.
Does this justify a separate code base though? Allowing the Xinclude
component to act on a sitemap parameter specified namespace should do.
>
> Vadim
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
--
-= Ivelin =-
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: XInclude Transformer vs CInlude Transformer
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Mattam [mailto:mattam@netcourrier.com]
>
> Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]:
>
> |
> | Two almost identical transformers are confusing me.
> | What is the difference between the two?
> | Should one be deprecated?
> |
> | I'd vote for the one which implements the W3C XInclude spec closest.
> | Maybe it should take the best of the other one.
> |
>
> CInclude allows cocoon:/ protocol, and XInclude tends to be a strict
> implementation of the standard. Maybe keeping only XInclude while
allowing the
> cocoon:/ protocol (with a switch?) would be the better.
That's not right; XInclude also works with cocoon: protocol, they both
use Cocoon's resolver.
IIRC, the reason of CInclude existence is completely different: if you
remove CInclude, it will be more complicated to serve documents with
inclusions and with tags in xinclude namespace. Right now, this is not
an issue: create document with xinclude *and* cinclude tags, process it
through cinclude, and xinclude will remain intact, no sweat.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: XInclude Transformer vs CInlude Transformer
Posted by John Morrison <jo...@ntlworld.com>.
> From: Mattam [mailto:mattam@netcourrier.com]
> Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]:
>
> |
> | Two almost identical transformers are confusing me.
> | What is the difference between the two?
> | Should one be deprecated?
> |
> | I'd vote for the one which implements the W3C XInclude spec closest.
> | Maybe it should take the best of the other one.
> |
>
> CInclude allows cocoon:/ protocol, and XInclude tends to be a
> strict implementation of the standard. Maybe keeping only
> XInclude while allowing the cocoon:/ protocol (with a switch?)
> would be the better.
XInclude also allows the cocoon:/ protocol. I'm not sure
however about the cocoon:raw: one...
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XInclude Transformer vs CInlude Transformer
Posted by Mattam <ma...@netcourrier.com>.
Ivelin Ivanov [Sun, 09 Jun 2002 11:22:07 -0500]:
|
| Two almost identical transformers are confusing me.
| What is the difference between the two?
| Should one be deprecated?
|
| I'd vote for the one which implements the W3C XInclude spec closest.
| Maybe it should take the best of the other one.
|
CInclude allows cocoon:/ protocol, and XInclude tends to be a strict implementation of the standard. Maybe keeping only XInclude while allowing the cocoon:/ protocol (with a switch?) would be the better.
--
"Not only is there no God, but try finding a plumber on Sunday. "
- Woody Allen
MaT|TaM (http://mattam.ath.cx)