GNUe Traffic #84 For 7�Jun�2003

Editor: Peter Sullivan

By Arturas Kriukovas �and� Peter Sullivan

RDBMS warz - "The only people I know who object to mysql are in this channel. =)" - "must be the only smart guys you talk to are in this channel ;/)"

Table Of Contents

• Printer-Friendly Format
• Text Format
• XML Source
• Introduction
• Threads Covered

  1.	28�May�2003	(1 post)	Designer's dependencies for Python and wxPython
  2.	29�May�2003	(1 post)	Bayonne developments
  3.	29�May�2003�-�2�Jun�2003		New relase and Debian packaging strategy
  4.	30�May�2003		SAP-DB and MySQL join forces?
  5.	1�Jun�2003�-�3�Jun�2003		Arias, fork of NOLA

Introduction

1. Designer's dependencies for Python and wxPython

28�May�2003 (1 post) Archive Link: "[GNUe]Changes to the minimum requirements (Python/wxPython)"

Summary By Peter Sullivan

Topics: Designer

People: Jason Cater

Jason Cater announced "The next version of GNUe Designer will no longer support Python 2.0 or wxPython 2.2 . The new minimum requirements will be Python 2.1+ and wxPython 2.4.0+" . Python 2.1 had been out for some time, but wxPython 2.4 was rather newer - however, he felt "the change in requirements will benefit everyone in the long run. I will be able to spend more time adding features/fixing shortcomings in GNUe Designer rather than working around wx oddities, as has primarily been the case since the 0.4.x releases." wxPython 2.4 was already in most of the leading GNU/Linux distributions, with the notable exception of the Debian stable distribution ('woody'). However, he had done some (strictly unofficial!) Debian woody packages, backporting the wxPython packages from Debian unstable, which were available on the GNU Enterprise website.

2. Bayonne developments

29�May�2003 (1 post) Archive Link: "[GNUe]Notes on Bayonne integration development roadmap..."

Summary By Peter Sullivan

Topics: Bayonne

People: David Sugar

David Sugar summarised "some areas of current Bayonne development related to the upcoming 1.3 release and beyond" :

• External Bayonne Integration Scripting
  . As well as allowing scripts more access to the Bayonne server, it
  can be used to output a valid html document and may be ran directly as a cgi
  and
  can also be used to generate and deliver mime attached email through sendmail
  .
  External scripting will also be invokable from the Bayonne scheduler. This will allow Bayonne's job scheduler to be used in a complete solution rather than using cron.
• Apennine returns
  , offering
  authenticated access to Bayonne services through "soap" and will support soap serverlets that can then be created to support specific bayonne applications.
• Python and Bayonne
  - a "pybayonne" project would start with
  a python plugin that allows python to integrate with bayonne much the same way the new external scripting does
  .
• Giza speech recognition services
  -
  Work has also been done on creating speech recognition services in Bayonne
  and the ability for Bayonne to route audio to a seperate server.

3. New relase and Debian packaging strategy

29�May�2003�-�2�Jun�2003�Archive Link: "[IRC] 29 May 2003"

Summary By Arturas Kriukovas

People: James Thompson,�Jeff Bailey,�Jan Ischebeck,�Derek Neighbors

James Thompson (jamest) announced that "0.5.1 is out real soon now. The ui driver work alone was worth a release" . He said there was pending "buglist cleanup on designer - i really wanted to get input masks in there too but I have yet to start work on them so I'd say that aint going to happen" . Jeff Bailey (jbailey) noticed "it would be nice to fix the .deb's before 0.5.1" so it would be possible to use the realeased versions for the Debian packages. Jan Ischebeck (siesel) also noticed it would be good if Jeff "could package the actual cvs instead of the 0.5.0 release" . Derek Neighbors (derek) disagreed with the discussion: "we made a CONSCIENCE decision to not bundle cvs several months back. We need to get 'off' using cvs if we want people to use stuff in production and we want stuff in woody. If we want to package a 'cvs' version we need to do separate cvs packages (in the form of snapshots), but i dont think its worth the time unless its automated" . Jeff said he could setup automated snapshot packages, but wondered if anyone would actually use them? Jan thought this possibly would be "needed short before a new release" .

Later, James said he would like "debs working for 0.5.1 as well - i wouldn't use snapshots" . Derek agreed with him - "as long as we are current on releases im happy" . Jan would like "to use snapshots for pre 0.5.1 versions, as I don't think that it makes sense to package 0.5.0 without any patches - IMHO its important to have debs to test BEFORE the 0.5.1 version is out, rather than to have to fix bugs for the release first and than have to fix bugs in debs afterwards." He "never wanted OFFICIAL debian packages from cvs, rather than snapshots to do developing and testing" Jeff explained - "I'm not thinking official debs, but snapshots that I could post on people.debian.org. If I did that, i'd prefer to make them only for sid, though (and they'd never be uploaded to the main archive)" . Jan agreed that "SID would be ok for me" .

Some days later, Jan was interested in progress on GNUe packaging. Jeff said he "haven't had a chance to sit down with" James as of time of writing. Jan asked where he could get latest debian packaging diffs. Jeff thought he had "that thing setup for apt-get source. I've been using DBS packaging, so it's not suitable to keep them in CVS." He was going to update the GNUe Debian packages to use "the dbs tarball functionality" - this would be easier to work with, and open up the possibility of producing automated Debian packages from CVS. "At that point I could more easily integrate the packaging into" GNUe's own CVS again, but he personally was not keen on this - in principle, "all the fiddling in the debian/ directories" was really the responsibility of the Debian maintainer, not the "upstream" developers of the underlying software. Jan felt "the only advantage of having debian directories in cvs is that its easier to apply changes etc." .

4. SAP-DB and MySQL join forces?

30�May�2003�Archive Link: "[IRC] 30 May 2003"

Summary By Peter Sullivan

Topics: Common

People: Jason Cater,�Derek Neighbors

Further to previous discussions about using SAB-DB as a back-end database for GNUe in various threads (including Issue�#53, Section�#16� (25�Oct�2002:�SAP-DB as a free (GPL) database back-end to GNUe) ), Jason Cater (jcater) noted "all this negativity around the SAP-DB license change - lots of fud" (fear, uncertainty, doubt). Derek Neighbors (dneighbo) felt that "SAP-DB went about it all wrong. the more i see the change and talk to SAP, the more I _like_ the change. My understanding is that they will continue to own SAP-DB and develop it. They are jsut 'sub licensing' it to MySQL AB - and MySQL AB will add some 'features/fluff' and put under a different license and try to make money on it. In doing so SAP-DB has become protective (in a good way) and made the whole shooting match GPL - instead of just the engine (so they can continue to make money sub licensing). Thtis to me is good news not bad news - my original understanding is they were selling SAP-DB to MySQL and never touching it again" , but it looked now as if this was not the case. Some of the complaints were from people who objected that they had "made the client libraries GPL (instead of LGPL as they used to be)" , but the strong copyleft of the full GNU General Public License (as opposed to the weaker Lesser GPL) would actually encourage people to release SAP-DB-based products as free software. The discussions drifted into a general discussion of the merits of the existing MySQL database system, including issues like scalability, views and sub-selects.

5. Arias, fork of NOLA

1�Jun�2003�-�3�Jun�2003�Archive Link: "[IRC] 01 Jun 2003"

Summary By Peter Sullivan

Topics: Financials (Accounting), Small Business, Inventory

People: Chan Min Wai,�Dmitry Sorokin,�Derek Neighbors,�ra3vat

Chan Min Wai (dcmwai) said he was "the developer of arias" , a fork of the NOLA software, previously discussed in several threads, including Issue�#57, Section�#5� (23�Nov�2002:�Nola/acclite original author spotted in #gnuenterprise) . Dmitry Sorokin (ra3vat) noted that "it was discussed at one time to use nola db schema for gnue accounting" , but he was not sure what the outcome of this had been. Looking at the screenshots for aria, Dmitry felt they "may be easily converted to gnue forms" . Chan felt that "gnue proved to be more customizable" but that "arias just need a web browser" as a client, as the application was written in PHP with MySQL as the back-end database. Dmitry noted that, as of time of writing, "gnue is mostly a set of tools" - "we just do not have official gnue applications like acounting" . Chan was thinking "maybe I can intreged gnue to arias so that when having web access can also have gnue access" as well.

Some days later, Derek Neighbors (derek) said that some of the GNUe developers had "snarfed the NOLA tree sometime ago - and redid their structure - and fixed a lot of the bugs - and put in private cvs" under the name acclite with the intention of porting "it to the GNU Enterprise Framework" . More recently, he had looked at arias and considered using it as the basis for GNUe Small Business (gnue-sb), but had not gone any further with this - gnue-sb "was going really well until real life hit me :(" Chan asked if the changes from NOLA to acclite had included any fixes to Inventory - he was looking at this area next, and would prefer not to have to re-fix anything that the GNUe developers had already fixed. Derek said they had not really looked at Inventory - the priority had been to convert it to use PostgreSQL instead of MySQL, and then a few bugs in the accounting. This first priority had taken quite a bit of work, as NOLA took full advantedge of the non-standard features of MySQL (e.g. assigning NULL to a primary key).

Derek admitted he was not really keen on web applications, especially for Financials, and had been looking to 'clean up' NOLA as a prelude to converting it to the GNU Enterprise framework (i.e. using Forms, Reports and Navigator). Chan asked if the GNUe developers would consider contributing their patches in acclite to arias. Derek said that, if the directory structure was fixed and PostgreSQL support added to arias, he personally "would gladly do all future fixes on ARIAS and would consider working directly with ARIAS on schemas" - he could even envisage gnue-sb and arias as complementary projects (gnue-sb using the GNUe Tools and arias using PHP) sharing the same schema. "ultimately we could have ARIAS use the web UI of the GNU Enterprise Framework - it just isnt ready yet" . He explained that the concept of GNUe was "a framework - so you write one "form" - and instantly (without code modifications) it will run on curses (text based ui), win32, mac, gtk2, qt, html etc - just our 'html' client isnt ready yet" .

Chan said he wasn't keen on the NOLA directory structure either, but that "we don't have time to clean all that creep/ - so we plan to clean up the creep on the rewrite... and For the time being, I will just stick to the old structure and fix all bug. Once a Stable release is being release... A rewrite will begain..." Derek wondered if it might be easier to apply the patches from arias to acclite - "and have postgres support and a clean dir structure with minial work - but im not pushing that" . Chan was worried about upgrade paths for existing NOLA users, but Derek "suspects the number of folks using NOLA that arent noguska's customers is so small - that backwards compatiability would be the most minimal of concerns" - acclite had no schema changes from NOLA.

�

�

�

�

�

�

Sharon And Joy
�