[Z3lab] portal specifications

[Paul Everitt]

On May 13, 2005, at 9:34 PM, Martijn Faassen wrote:

> Julien Anguenot wrote:
> [snip]
>
>>> As for the website, my personal preference would be that we see  
>>> this as
>>> a publication medium primarily and not as a collaboration medium. We
>>> could for instance use CPS for publishing "finished" design  
>>> content to
>>> the web for public consumption and the like, and to draw new  
>>> people into
>>> the project.
>>>
>>> The alternative which I think is presented is to use the  
>>> collaboration
>>> features of CPS to do this. I myself do not have a lot of experience
>>> with these. What do others think?
>>>
>> yup Why CPS ?
>> Because :
>>  1. It proposes everything almost out of the box. (Just need to  
>> add the
>> specific content types and the layout)
>>  2. Jean-Marc and I proposed to setup the portal and we can have it
>> running by this week-end.
>>  3. it proposes both collaborative and publication features all in  
>> one.
>> Let's not fight again for the the portal technology... :(
>>
>
> This is why I carefully separated the collaboration features from  
> the publication features in this discussion. I'm absolutely fine  
> with using CPS for publication of design documents and there is no  
> debate from me on this whatsoever.
>
> I'm just wondering whether we should use it for *collaboration* on  
> these documents as well. I realize it's called Collaborative Portal  
> Server, but using a CMS is not the *standard* way open source  
> developers tend to work and may increase barriers to entry.
>
> Anyway, I understand now that you'd like to do collaboration by  
> passing around OpenOffice and DocBook documents on a CPS site. The  
> alternative I'm proposing is restructured text and a few binary  
> assets like images in svn.
>
> CPS + DocBook/Openoffice
> ------------------------
>
> Advantages
>
> * very easy web publication thanks to integration with OpenOffice,  
> DocBook, etc
>
> * Lots of knowledge and resources at Nuxeo.
>
> * DocBook + OpenOffice can be exported with lots of things.
>
> * CMS and OpenOffice more accessible to non-geeks.
>
> Disadvantages
>
> * higher barrier to entry for J. Random Open Source Developer
>
> * harder to do simple 'diff' to see what changed
>
> svn + ReST
> ----------
>
> Advantages
>
> * lightweight
>
> * svn diffs, checkin mailing lists with diffs, help see what's  
> going on.
>
> * Compatible with what Zope 3 is doing already.
>
> * Increased familiarity for developers; lots of people can handle  
> svn and plaintext.
>
> * Can be exported easily to HTML and simple PDF.
>
> * Documentation can be kept in synch with the code, doctests.
>
> Disadvantages
>
> * Somewhat harder to publish end result to the web as no  
> integration with CMS.
>
> * Less programmable features, all very flat and plain.

Very good writeup of the pros and cons.

I propose that we tolerate both approaches.  Ultimately I think  
Martijn's view will prove right, that developers will jot things down  
in an Emacs buffer as they are writing code.

However, I'm personally interested in the OO.o/Docbook approach the  
Julien described and will use it as soon as he gives me a login.

Moreover, I think we should recognize Julien and Jean-Marc's  
initiative, just like we should recognize Philipp's initiative.  I  
think the two directions can work together.

--Paul