incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Jaskurzyński <>
Subject Re: GSoC: ODF Command Line Tools Application
Date Tue, 27 Mar 2012 20:46:08 GMT

I submitted my application via google melange system. The main change
that I made is to leave feature of html importing and exporting. I
realized that this feature is too hard to do in three months. There
will be only plain text and csv import export.
Can you give me some feedback? What should I add to my application?
What do you think, is this project will be accepted?


2012/3/26 Rony G. Flatscher (Apache) <>:
> On 26.03.2012 17:27, Rob Weir wrote:
>> On Fri, Mar 23, 2012 at 10:52 AM, Michał Jaskurzyński <>wrote:
>>> What do you think about this projekt:
>>>  ? 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.
> No, BSF4ooRexx is a wrapper for Java (!), hence the shown ooRexx programs are interacting
> with the Java APIs, ie. the ODF Toolkit itself. However the semantics are such of the
> typed, caseless scripting language ooRexx. As a result the same programs run unchanged
not only on
> Linux, but also on Windows and/or MacOSX.
> In addition (not shown in the Bachelor thesis) there is special support for interfacing
> directly with OpenOffice in the form of an oxt-extension. This special support brings
forward the
> semantics of dynamic types and caselessness to the UNO framework on which OpenOffice
is based. (I am
> not aware of a comparable Perl module, Python is currently restricted to the Python shipped
> OpenOffice.)
> The overall aim is to make it easy for professional, but also non-professional programmers
> ("enduser" resp. "business" programmers) to interact with Java and/or OpenOffice easily
in a
> platform independent manner.
> Of course, like any other language, one could apply the language ooRexx for creating
filters that
> read from stdin and write to stdout (to allow the creation of pipes).
> Having said that, still the following applies: there are many ways (and languages) to
approach the
> task at hand, and being a pragmatic person, any approach that solves the problem at hand
> sufficiently is probably fine ...
> ---rony
> P.S.: Ad "dynamically typed" and  "caselessness": if you look at the few nutshell examples
of the
> Bachelor paper, the Rexx programs do not have any type declarations which eases/simplifies
> remarkably for (especially for enduser/business) programmers; also, caselessness means
that no
> runtime errors are created if the names of methods and fields are not spelled out with
the correct
> case, e.g. "odfTable~getCellByPosition(0,4)" has the same effect as "odfTable  ~
> GETcellBYpositioN('0',  4)".
> Making this behaviour available to (enduser/business) programmers is motivated by the
> "human-oriented" paradigm of the Rexx language philosophy and the speed of modern computers,
> allow for implementations of such principles with a responsiveness to the user, that
is totally
> acceptable for them. It eases coding for professional programmers alike (especially for
> scripts).

View raw message