[Zope3-dev] Status of reST

Stephan Richter stephan.richter@tufts.edu
Fri, 11 Apr 2003 10:34:25 -0400


On Wednesday 09 April 2003 13:11, Jeffrey P Shell wrote:
> I would like to, but time is the bastard.  There are some important
> issues that need clearing first anyways:
>
> Docutils Dependency: do we keep a copy of docutils in our repository
> and update as needed?  There's still no real release process beyond
> nightly 'builds' for docutils (I think the last release is the very
> antiquated 0.2).  It's probably better *not* to put docutils in the
> source tree, but there are still some API change possibilities.  I
> doubt we'll do any *heavily* customized parsers or writers, so this
> isn't a huge issue.

Zope 2 contains a docutils copy. We could do the same or require an additional 
installation step, which would not be that great. I have implemented ReST in 
for the zwiki for Z3 product and require the user to install docutils 
thenselves.

The problem is that docutils is just over-engineered...as Jim always says, 
premature generalization is bad. We only need a really small subset of all 
this framework.

> reST sandbox works: There are a couple of useful tools in the reST
> "sandbox" contributed by various people using docutils.  There are a
> couple that may be of interest to us, particularly Bill Bumgarner's
> 'DocArticle' writer, which generates HTML that doesn't depend on the
> docutils stylesheet.  

I use the sandbox as is. I have not written a special formatter object for 
ZWiki. I used in fact Simon's trick to strip of everything outside the body 
tag.

> The docutils stylesheet is great and yields
> beautiful standalone documents, but it can create problems when being
> used to generate HTML that needs to integrate with other HTML.  There
> is also a clever Wiki parser that finds potential wiki names during
> reST's processing/parsing time, which can sidestep potential
> double-processing (a situation that can occur in regular ZWiki).  There
> are some other useful works in the sandbox as well, along with some
> stuff I've already written to return the body of a document using
> reST's DOM-ish API's, allowing the content to be used in any content
> system. 

Cool.

> My concerns here are:
>
>    - A lot of useful work has already been done by other people
>      that we could use.

Could you give a list of useful tools and modules? I really think we do not 
that much. We should not make the integration of reST a major project in 
itself. It should be dead-simple to use, just like ZPT and DTML.

>    - It's all published under different open source licenses.

That is a major issue for us! I would prefer to use tools only under one 
additional license. What are the various license schemes?

>    - Maintaining our own copies could be time consuming, but
>      too many dependencies are annoying for end users.

We do not need to "maintain" a copy, just provide one; in fact, I would not 
change anything in our copy of docutils ever.

> I'm not sure what to do about these two issues (which is all basically
> one big dependency issue).  I think reST has more than enough benefits
> to offer us, but there are still a couple of hurdles to deal with
> first. :\

Let's figure out the licenses; once we agree on something, I think we should 
just ass reST to the repository. We really need it at a lot of places.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training