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 Mon, 02 Apr 2012 16:48:54 GMT

I updated my application
Your comments will be welcome.

Michal Jaskurzynski

W dniu 27 marca 2012 22:46 użytkownik Michał Jaskurzyński
<> napisał:
> Hi,
> 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?
> Michal
> 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 dynamically
>> 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 with
>> 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
>> "human-oriented" paradigm of the Rexx language philosophy and the speed of modern
computers, which
>> 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 creating
>> scripts).

View raw message