From odf-dev-return-789-apmail-incubator-odf-dev-archive=incubator.apache.org@incubator.apache.org Mon Mar 26 19:24:09 2012 Return-Path: X-Original-To: apmail-incubator-odf-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-odf-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 925AD9E60 for ; Mon, 26 Mar 2012 19:24:09 +0000 (UTC) Received: (qmail 35731 invoked by uid 500); 26 Mar 2012 19:24:09 -0000 Delivered-To: apmail-incubator-odf-dev-archive@incubator.apache.org Received: (qmail 35705 invoked by uid 500); 26 Mar 2012 19:24:09 -0000 Mailing-List: contact odf-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: odf-dev@incubator.apache.org Delivered-To: mailing list odf-dev@incubator.apache.org Received: (qmail 35697 invoked by uid 99); 26 Mar 2012 19:24:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Mar 2012 19:24:09 +0000 X-ASF-Spam-Status: No, hits=-1.6 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [137.208.3.15] (HELO strozzi.wu-wien.ac.at) (137.208.3.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Mar 2012 19:24:03 +0000 Received: from [137.208.114.24] (rony.wu-wien.ac.at [137.208.114.24]) (authenticated bits=0) by strozzi.wu-wien.ac.at (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2QJNdU6007913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Mar 2012 21:23:40 +0200 Message-ID: <4F70C255.8050704@apache.org> Date: Mon, 26 Mar 2012 21:24:05 +0200 From: "Rony G. Flatscher (Apache)" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: odf-dev@incubator.apache.org Subject: Re: GSoC: ODF Command Line Tools Application References: <4F67862B.4020907@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.1 at herpes X-Virus-Status: Clean X-Virus-Checked: Checked by ClamAV on apache.org 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: >> 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. No, BSF4ooRexx is a wrapper for Java (!), hence the shown ooRexx programs are interacting directly 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 ooRexx 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 coding 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, 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).