Am Mit, 2002-08-28 um 20.28 schrieb Niels Petersen:

Chris, Max, Andreas,

thanks for your comments. I am still wondering if /hoping Zope is the right tool. As I said I am pretty technical but completely new to Zope/Phyton and for now I "just" have a urgent need I thought is pretty generic:

* Setup a "portal" where a small team/community can share docs, links and maybe discussions. * Docs must be categorized (users can add new categories), provide upload capability * UI must be super-simple (no Zope management stuff) - simply allow users these basic features (create new doc, upload, create news/links/discussio) and nothing more

To give you guys an idea of a pretty good solution from the Evil Empire - look at MSFT Team Services (http://www.microsoft.com/frontpage/sharepoint/fastfacts.htm) or the

So why do I just not give in and use MSFT ? 1) I prefer open source alternatives to the evil empire

2) I like what I see in Zope/Plone and _think_ it could fit but I need a minimum set of out-of-the-box features I currently don't see (seems like zope has too much stuff <- this always happen in tech communities - geeky stuff takes overhand)

3) Zope is customizable so once I get the hand on it I can see myself adding new features that closed MSFT prods do not allow...

So tell me - are my req's that stange? How much work would it be to get Zope/Plone close to the MSFT Team Services?

Niels

Re: the ZODB: One pretty important requirement is that members should be able to take a snapshot of content from the site for offline work (reading while flying or otherwise offline) Well, reading is easy: Setup your site, that you can switch on a "readonly" skin by setting either a cookie or a parameter. (Easier with cookie, because you do not have to generate urls with "&readonly=1" appended)

Then, to check out the documents: wget --load-cookies myreadonlycookie.txt --http-user USER --http-passwd PASSWORD ServerUrl. Additional benefit: The person checking out is allowed only to fetch documents he is authorized to check out in real. If you want to be able to modify the files offline, you've got to solve two things: -) Modifying. Either provide a local zope on the laptop, or allow the user to modify the files on the filesystem. -) Syncing. Just do a md5sum on checkout. When syncing, you have these cases: oldweb | laptop | newweb | explanation ABC | ABC | XYZ | the online version has been updated. ABC | DEF | ABC | the offline version has been updated. ABC | DEF | XYZ | both has been updated. Resolve conflict by human.

Haveing everything in a file system (that can be mapped) is the easiest way..I think. I had mixed emperienced with Zope's WebDAV - Not really. You might loose some important properties which are not part of the file. (like keywords, etc.) Just setup additionally to the online version a service that deals with checking out (and optionally in) filesystem versions.

This can be centralized like in downloading a .zip file, or it can be a client program that access the Zope application by xmlrpc, ...

basically one can mostly not use W2K explorer for copy/paste - explorer<->Zope WebDav just don't work well together and I cannot change the fact that 99% of team members are on W2K clients..

As noted above by storing the stuff in the filesystem you do not get really a solution: -) it ignores permissions. (For a small team this might be ok.) -) it clutters the filesystem (also the checkout) with more or less cryptic metainformation. -) it clutters the filesystem with versioning informations, etc. Consider something like the following setup: online zope with a systematic organization (be it real folders, be it home folders + ZCatalog virtual folders by keyword) additionally. An offline copy of your site. (Could be possibly the a clone of the online one without the data and unnecessary user objects) And a small python program that installs this local Zope and supports syncs between these twos. Getting it right should be less than a week work, but then you might have problems getting used to Zope. Andreas