OK, sorry about raising an issue that I was not around to comment on.

First, there seems to be a good deal of confusion on what FileSystemSite
or the DirectoryView portions of CMF are.  They are simply a way to have
Zope2 programmatic content stored directly on the filesystem, including
dtml, page templates, python scripts and zsql methods, among others.

FileSystemSite does not allow "filesystem access" in the usual
sense, access is read-only;  objects cannot be created on the filesystem
through ZMI.  Arbitrary filetypes cannot be easily stored on the 
filesystem
at all (In fact I have no interest in that, I can always store such
files in Apache-space.)

This, or the CMF version, or something like it should be included because 
it is a large step up from pure TTW development in that it makes 
using conventional OS-level tools easier, including revision control 
systems
and editors.  It also gets the job done without all the effort of zope2
python based products.  While products are important, and indeed, at this
point the zope3 way, they don't scale down very well; and for one-off,
will never meet the external world, systems; they represent a lot of
wasted motion.  FilesSystemSite and DirectoryView represent a 
"middle way" between pure TTW and pure file-system development.

This is an idea that has come up at least three times, Ape was partially
inspired by it, the CMF suite has such components, and it was thought
to be worthwhile to pull out of CMF.

CMF is a lot of overhead to pull in just to get DirectoryView, and exactly
what to install to get DirectoryView and as little else as possible 
installed
is not documented.  In fact, neither is very well documented.

I don't care whether DirectoryView, or FileSystemSite, or yet another
implementation is blessed.  However, the idea of permitting all 
programmatic
content to be stored directly on the filesystem has merit and  has been
developed multiple times.  It is an option that belongs in zope2 core.

Note:  if one is chosen, I will write a draft of a chapter for the "Zope 
Book"
for the blessed implementation.

jim penny

[EMAIL PROTECTED] wrote on 03/26/2006 09:56:01 AM:

> Tino Wildenhain wrote:
> 
> > Maybe its just me but I personally dont like direct filesystem
> > access in the core - if someone wants it, (s)he can pick from
> > the 3rd party products - maybe there can be a list of recommended
> > (active maintained) products? Direct access products should also
> > carry some easily understandable warnings.
> 
> I can understand that point of view for products that allow writing to 
> the filesystem, but, conceptually, what's the difference between 
> read-only "filesystem access" and a standard filesystem product?
> 
> None, I think, but then I may have misunderstood the purpose of 
> FileSystemSite, and friends.
> 
> Tim
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
> 

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to