cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hartle <mhar...@hartle-klug.com>
Subject Re: [RT] Enhancing Cocoon Visibility
Date Tue, 15 Jan 2002 20:25:30 GMT
Stefano Mazzocchi wrote:

>what to do?
>
>I see a number of solutions (you have more, make yourself heard):
>
> 1) adding an implicit 'cocoon-status' resource (for example
>/about-cocoon)
>
> 2) adding a implicit 'about' resource view (for example
>?cocoon-view='about')
>
> 3) adding cocoon-specific HTTP header to the response (for example
>x-cocoon: 2.0.12)
>
>Of course, we must prevent people from having the chance to disable this
>so we must make sure things have a very low impact on resource.
>
The first impression of mine is that approaching a viable interest like 
this scares the shit out of me, pardon my language please.

Yes, I mostly agree on your assessment, both Cocoon and its users 
benefit from the visibility, but enforcing visibility by either 
polluting their URI space (1) or "extending" someone elses web 
application semantics (2) is something I would consider as an offence to 
the current user base and incompatible to the concept of free 
participation. I would consider (3) to be the least intrusive one, but 
preventing people to disable this either due to their personal taste or 
for a real need of theirs is dangerous:

* Being able to question version information to automatically exploit 
defects or security holes is something that I started hating when I had 
my first bigger source-level look into a project, which was the de-facto 
standard DNS server BIND; a certain, specific DNS query (class=chaos, 
type=txt) makes bind respond with more than sufficient versioning 
information, a perfect basis for automation. I *do* believe in 
publically declaring defects and security holes, but I am against making 
it *that* easy for script kiddies.

* Not being able to turn of versioning information opens up a 
possibility for articifical incompatibilities or product capabilities; I 
do not yet expect this to happen, but I'd hate it to see some commercial 
tool of mine either refuse to work with a cocoon-based web system or 
request an upgrade to a pro version I directly could buy online.


I understand the hunger for visibility for this project, but enforcing 
this is the wrong way; my guess is that this would only spark an 
open-source project for filtering this out, and any measures taken to 
protect that versioning information from being stomped out of the 
original source code would only make it worse. Instead, let's turn to 
make people think about freely supporting Cocoon instead; do we have a 
"this site is powered by cocoon" button readily / widely available ? We 
might put that directly into each and every release for a start, 
encouraging people to use it whereever possible.

Concerning visibility, what about writing a book about Cocoon as a 
community project, publishing it and using any what-so-ever-income to 
help fund Apache ? What about writing articles for computer magazines 
such as c't or iX in Germany ?

Best regards,

Michael Hartle


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message