incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: GSoC: ODF Command Line Tools Application
Date Mon, 26 Mar 2012 15:27:10 GMT
On Fri, Mar 23, 2012 at 10:52 AM, Michał Jaskurzyński <jaskoola@gmail.com>wrote:

> What do you think about this projekt:
> http://wi.wu.ac.at/rgf/diplomarbeiten/#bakk_201203a  ? Is it
> sufficient? Should ODF Command Line Tools be closed or should use this
> bachelor paper and extend it?
>
>

Hi Michal,  I have not had time to read the entire paper, but I did browse
through it, especially the code samples.

It looks like it is a REXX wrapper of the ODF Toolkit, with an abstraction
level similar to our Simple API.     There are other ODF libraries out
there as well, for other languages, such as:

python: http://pypi.python.org/pypi/lpod-python

perl: http://search.cpan.org/~jmgdoc/OpenOffice-OODoc/

These are useful, but I don't think it satisfies the exact same need as the
command line tools would.  I think it is the difference between document
manipulation and text processing.  We have a variety of tools that operate
on plain, ASCII text, from grep, diff, sed, awk, sort, uniq, cat, etc.
These are doing simple text processing, but doing it in a way that more
powerful tool chains can be build from them.  A scripting language that
allows manipulation of ODF documents is good.  But it is still at a lower
level.  It offers get/set methods for content at a fine-grained level.  But
where are the more complex text processing actions?

Of course, you could build the more complex operations on top of a
scripting wrapper.  So these approaches are complementary.

Btw, I added some more info to the idea document:

https://issues.apache.org/jira/browse/ODFTOOLKIT-308

-Rob




> WBR
> Michal
>
> 2012/3/21 Rob Weir <robweir@apache.org>:
> > On Wed, Mar 21, 2012 at 10:34 AM, Michał Jaskurzyński
> > <jaskoola@gmail.com> wrote:
> >> I would like to use JavaCC Parser Generator for parsing scripts. What
> >> do you think about that? Are there any obstacles that I don't know?
> >>
> >
> > In general, the use of 3rd party code in Apache projects is allowed,
> > provided we have access to the code under a compatible open source
> > license.
> >
> > The thing to check is whether JavaCC puts any restrictions on the
> > generated code.  Some "compiler compilers" (like early versions of
> > Bison) put a copyleft license on generated code.  This would not be
> > compatible with the Apache license.
> >
> > Looking at JavaCC we see this license:
> >
> > "Copyright (c) 2006, Sun Microsystems, Inc.
> > All rights reserved.
> >
> > Redistribution and use in source and binary forms, with or without
> > modification, are permitted provided that the following conditions are
> met:
> >
> >    * Redistributions of source code must retain the above copyright
> notice,
> >      this list of conditions and the following disclaimer.
> >    * Redistributions in binary form must reproduce the above copyright
> >      notice, this list of conditions and the following disclaimer in the
> >      documentation and/or other materials provided with the distribution.
> >    * Neither the name of the Sun Microsystems, Inc. nor the names of its
> >      contributors may be used to endorse or promote products derived from
> >      this software without specific prior written permission.
> >
> > THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> > AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> > IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> > ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> > LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> > SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> > INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> > CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> > ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> > THE POSSIBILITY OF SUCH DAMAGE."
> >
> > So I think this will be OK.  From a technical perspective, I think
> > this is a good way to go, especially if this evolves into an
> > interpreted document processing language.
> >
> > -Rob
> >
> >> WBR
> >> Michal
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message