cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@cocoon.apache.org
Subject [Cocoon Wiki] Updated: Doco
Date Fri, 09 Jul 2004 11:46:18 GMT
   Date: 2004-07-09T04:46:18
   Editor: DerekLastname <dhohls@csir.co.za>
   Wiki: Cocoon Wiki
   Page: Doco
   URL: http://wiki.apache.org/cocoon/Doco

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -76,7 +76,7 @@
 
 ''How about using the hierarchical repository structure for that?? since the repository structure
has to be managed somehow anyway... DavidNuescheler''. 
 
-''A hierarchical structure indicates a unique placing, or, given the ability to create symbolic
links, a preferred location for that resource. This also implies that someone (might not be
the author of the page, but still a person) must decide where the page resides. This decision
is often the most expensive in decisional terms, because its hard to measure the judgment
made, especially in environments like open source where there is no figure for an editor.
Also, the location of a particular resource in a hierarchy seems to limit the ability to reuse
that resource in another context and, potentially, without human intervention... [:StefanoMazzocchi]''
+''A hierarchical structure indicates a unique placing, or, given the ability to create symbolic
links, a preferred location for that resource. This also implies that someone (might not be
the author of the page, but still a person) must decide where the page resides. This decision
is often the most expensive in decisional terms, because its hard to measure the judgment
made, especially in environments like open source where there is no figure for an editor.
Also, the location of a particular resource in a hierarchy seems to limit the ability to reuse
that resource in another context and, potentially, without human intervention... [:Stefanomazzocchi]''
 
 ''Hmmm... I would argue that hardlinks in a hierarchical repository structure would give
you the ability to display as many views on top of a hierarchy as you like, and by no means
 imply "human" intervention. 
@@ -107,7 +107,7 @@
 
 ''under the assumption that i understand the issue correctly... would the "reverse proxy"
remove forrest from the picture?? reverse-proxying on the live machine certainly would make
the roundtrip from the author to the live site much more responsive which should increase
sexyness? do you think the apache infrastructure group will like the dependency to a dynamic
(java based) system? if yes i think it might be beneficial to introduce a push based cache
invalidation for mod_cache... DavidNuescheler''. 
 
-''the mod_proxy/mod_cache couple are definately the way to go in a dynamic environment, still,
from both a political and community perspective, I think that using static content is the
way to go for now. But I do agree with you that in the future a transparent mod_proxy/mod_cache
situation with push-based (and IP-filtered to avoid DoS!) cache invalidation mechanism for
mod_cache would be extremely beneficial, for Doco and for many other situations, but at a
later stage...[:StefanoMazzocchi]''
+''the mod_proxy/mod_cache couple are definately the way to go in a dynamic environment, still,
from both a political and community perspective, I think that using static content is the
way to go for now. But I do agree with you that in the future a transparent mod_proxy/mod_cache
situation with push-based (and IP-filtered to avoid DoS!) cache invalidation mechanism for
mod_cache would be extremely beneficial, for Doco and for many other situations, but at a
later stage...[:Stefanomazzocchi]''
 
 === Workflow Issues ===
  1. how can we make the channels more secure? SSL on the editing part and PGP/SMIME signing
the mail replies?

Mime
View raw message