cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Kuhnle <>
Subject Re: Manually specifying a mounted sub sitemap's context
Date Mon, 11 Apr 2005 13:12:44 GMT
And I thought nobody would care about this small change :) Since Cocoon is 
all about access to many sources and generated XML, I as a developer am 
actually surprised that what works with URLs everywhere does not work with 
sitemap URLs. I think this is inconsistent, and when writing my initial 
posting I actually thought I'd found a bug...

Stefano Mazzocchi <> wrote on 10.04.2005 16:32:36:

> here is my rationale for the my everlasting -1 on a dynamic sitemap 
> (this -1 is there since 2000, and I'm not changing it).
> the sitemap is one of the key functionalities of cocoon, having it 
> dynamic would allow people to avoid fighting for a functionality and 
> work around it on their own.

They do this anyway. Making it harder to work around only will lead to 
uglier workarounds. Cocoon already is open to many kinds of "abuse" and 
workarounds. For the abuse category, see the "cocoon:"-nightmare-sitemap 
that Sylvain mentioned (it's not generated, I suppose). For the workaround 
category see Lenya's page envelope action, which delegates its work back 
to the sitemap, a concept that I find harder to understand and use than 
dynamically generated sitemaps. After all, you can allow access to the 
generated sitemap in debug mode, and then you have an 
all-in-one-place-sitemap-language-only-straighforward description of your 

> if you feel you need dynamic sitemaps, is because the sitemap is not 
> powerful enough for what you want to achieve. If that is the case *I* 
> want to fix the sitemap, rather than allow you to branch off and patch 
> it on your own.
> Sure, it takes longer and sure, it might not be exactly what you wanted, 

> but it will do the job, meet the requirements and make *everybody* 
> So, if you think there is a functionality missing in the sitemap, 
> propose a way to fix it, don't propose a way for you to route around it.

With dynamic sitemaps, I actually want to restrict the power of sitemaps 
to a certain subset. I agree that there may be better solutions ahead, but 
they are not here yet, and as you stated, they will take longer. Only, I'd 
like to have this feature sooner, so why not put it in there, since it 
will do only harm to people abusing it against our excplicit warning, and 
there seem to be other people that can put it to good use. Later, after we 
have developed a better solution, users can switch to it.

In any case, we will not be able to prevent abuse anyway, see the http: 
"workaround". And if we disallow the "cocoon:" protocol, people still can 
easily write a "get-around-this:" pseudo protocol.

Having generated sitemaps is a generic solution. We don't have to extend 
the sitemap language to achieve a goal that we have not yet anticipated in 
the sitmap language. On the other hand, sitemap language extensions are 
always solutions for one specific kind of problem. If I see that my 
sitemap XSLTs do one specific thing most of the time, I of course will try 
to propose a better solution and work on it, too. By then, I will have a 
good understanding of the problem and might be able to develop a good 
solution. Until then, my cocoon application works without ugly 

So what now? Basically three questions were discussed and need answering:

1. Should other protocols than "file:" for sitemaps be disallowed?
2. Should the "cocoon:" protocol be fixed so sitemaps can be generated?
3. Should sitemaps be mountable with a specified context?

Of course since I have written the original proposal, I am highly 
opiniated towards yes :)

re 1. Postings have shown that people already use other protocols for 
sitemaps. Sylvain needs resources, Carsten needs WebDAV, Gianugo has 
suggested JSR170 repos, I've seen Xindice and even protocol extensions 
like Lotus Domino access (btw: Is the ASF interested in a DominoGenerator? 
I happen to have one...). I have the feeling that if we discontinue this 
support, we'll see a lot of "why did the xy: protocol stop working" on 
cocoon-users. It's already out there, we use it, and I think there is no 
reason to take that away.

re 2. Generated sitemaps have found very strong opposition. The arguments 
against them were that it is better to make sitemaps more powerful than to 
generate them, that there are possible ways to abuse this feature, that 
there are security and (if the sitemap is not from a cacheable pipeline) 
performance issues. Performance is an implementation issue that can be 
solved. Since generated sitemaps can do no more harm than normal ones, I 
don't see why they should become a security issue. Abuse cannot be 
prevented. This leaves the "more powerful sitemaps" argument. If the 
sitemap++ does the job, developers will use it, if not, they can still 
implement a new feature with generation. So why not let the users choose?

re 3. The context question has met less resistance. Most of the discussion 
has been about the valid point where to put it, in the mount command or in 
the mounted sitemap, but this is an implementation detail. Since the 
change is fully upwards compatible, I can see no harm. Of course, there 
are other solutions for the mentioned problems, but I think specifying the 
context is a good solution for some of them. For example, if I want to 
mount user directories, but have the sitemap out of reach of the users, it 
seems like a good solution to me to do

<map:mount src="usersitemap.xmap" prefix="~joe/" 
<map:mount src="usersitemap.xmap" prefix="~jim/" 


View raw message