GNUe Traffic #22 For 30�Mar�2002

By Peter Sullivan

" We see before us a huge community of producers the members of which are unceasingly striving to deprive each other of the fruits of their collective labor - not by force, but on the whole in faithful compliance with legally established rules. In this respect, it is important to realize that the means of production - that is to say, the entire process of producing consumer goods as well as additional capital goods - may legally be, and for the most part are, the private property of individuals. " - Albert Einstein - early free software advocate?

Table Of Contents

Introduction

This Cousin covers the three main mailing lists for the GNU Enterprise project, gnue, gnue-dev and gnue-announce. For more information about GNUe, see their home page at http://www.gnuenterprise.org (http://www.gnuenterprise.org) . Details of the mailing lists can be found at http://mail.gnu.org/mailman/listinfo/gnue (http://mail.gnu.org/mailman/listinfo/gnue) , http://mail.gnu.org/mailman/listinfo/gnue-dev (http://mail.gnu.org/mailman/listinfo/gnue-dev) , http://mail.gnu.org/mailman/listinfo/gnue-announce (http://mail.gnu.org/mailman/listinfo/gnue-announce) .

It also covers the #gnuenterprise IRC channel. A great deal of development discussion for this project goes on in IRC. You can find #gnuenterprise on irc.openprojects.net:6667, or you can review the logs at http://www.gnuenterprise.org/irc-logs/ (http://www.gnuenterprise.org/irc-logs/) .

1. GNUe Reports proposal

19�Mar�2002�-�25�Mar�2002 (10 posts) Archive Link: "[Gnue-dev] GNUe Reports and xmlns, oh my!"

Topics: Reports

People: Jason Cater,�Derek Neighbors,�John Lenton,�James Thompson,�Peter Sullivan,�Stan Klein

Jason Cater said "After much time off from GNUe Reports, I'm finally able to tackle it once again." Most of the reporting engine was done, but he now wondered how to do " layout codes" . The reporting engine could just ignore these tags and they would "just be passed through to the output stream" . After considering various ugly ways of splitting the two types of tag, he "saw the light: XML Namespaces!" Layout tags could be given a namespace qualifier such as 'output:'. This would mean:

  1. The two different types of tag could be easily identified.
  2. It was compatible with how the XML parser already used in GNUe Reports worked.
  3. GNUe Designer could make use of the layout tags to graphically display how reports would look
  4. Other layouts could also be implemented as different namespaces
  5. Engines to produce other types of output (such as PDF, HTML or TeX) could be done directly rather than going via an XML stylesheet if desired.

On IRC (http://www.gnuenterprise.org/irc-logs/gnue-public.log.20Mar2002) , Derek said "you stole my thunder - reading your mail about half way through im thinking why not namespaces :)" . However, "you may have lost me on the formatting eninge - i think i would still see it as xslt - just the sytlesheet would be inline and would work with streams rather than files" , at least eventually. Jason Cater (jcater) said "the point of the "formatting engine" was options that this would allow IN THE FUTURE :) - i.e., going this route would leave room for other formatting options besides using external XSLT scripts - not that I wanted to pursue that at this time" . He would write further on "what we actually want the output xml stream to look like - I looked at datavision.sf.net - and it has some merit - but isn't exactly what I was envisioning" as it hard-coded positioning. He confirmed he was " not against internal XSLT - but I would write that as pluggable (with the default plug being the XSLT transformer)" .

Later, John Lenton (Chipaca) suggested that the XML tags for Reports should "look like the ones from forms - in fact if possible validate against the same DTDs" . Jason wasn't sure - "the datasources, et al will of course use the same markup - and I could see us creating a Designer wizard that basically asks for a Forms definition and creates a report based on the forms definition. But I'm not sure reports should be defined the same as forms" . James Thompson (jamest) said "i don't think they could be the same" as he would need some concepts in Reports (such as "grouping of fields" ) that weren't even valid concepts in Forms.

On the mailing list, Peter Sullivan suggested an alternative approach, using "two XML streams" , one for the formatting and one for the data. Later, he expanded his idea, giving some sample XML. " A GNUe report would be built up from two XML documents - the GNUe Report Format and the GNUe Report Data." . "The GNUe Reports 'engine' would transform these two documents into a composite XML document, processing and discarding all the "semantic" attributes, and leaving the formatting attributes" . This could then be "transformed again by the "Format Engine"" into the final presentation format. "you can start with a fairly small set of supported" format attributes and then expand them.

Jason said "this parallels one of my wishlist items: "skinnable" (or templated) reports." This would enable organisations to quickly apply corporate layout standards to the standard reports available with the packages, without having "to touch any of the actual Financial Reports (unless I actually want to modify the underlying reporting model.)" Peter said that " I think we are talking about slightly different levels of abstraction. I am initially talking about abstracting the dataset/results of the query from the output/formatting - which to an extent Reports must do already, no? (I'm assuming you don't have to redesign a report from scratch every time you want to refresh the data.) You seemed to have moved on to the next level of abstracting the 'cosmetic' formatting from the 'semantic' formatting." However, he thought " this would be a killer feature" .

Stan Klein said he had been thinking about various reporting tasks for GNUe, and suggested getting " the GNUe Reports output into a format appropriate for one of the word processors that use XML as their native format." Derek Neighbors said " This locks into that. The idea is that you simply export to xml and use xslt to transform into the xml of choice." . Jason said this was part of why he wanted to use XML namespaces. He already had "some mailmerge examples in the reports/samples/mailmerge directory, but these are klunky and use RTF instead of the word processor's native XML format. They are a hack, and not a graceful one at that." .

Earlier, Derek thought "the merge thing is much larger for document solutions like loan documents, medical forms and legal forms, but I think that should be a different tool perhaps." Jason said "I don't follow why this would be a separate tool. This is the exact kind of flexibility I'm looking for in Reports. The examples that Stan has given are actually the exact same needs I'm facing. If you see a repeating theme in all my Reports email, it is "flexibility.""

On IRC (http://www.gnuenterprise.org/irc-logs/gnue-public.log.21Mar2002) , Derek explained " what im thinking and what legal documents need are SMART forms" that could cope with multiple mortgage holders or addresses with a variable number of lines. Jason Cater (jcater) said "those are common reporting requirements - I have to account for multiline addresses in a lot of our customer service reports that mail letters to customers" . Derek said he was thinking of something more advanced, where "i have a lots of verbiage following that that is NOT in the database that is conditionally printed" depending on data in the database, such as U.S. state. - "you wouldnt want to necessarily make a custom DEED for each state - but rather dynamically build the form based on some rules" . Jason said "I do conditional reports all the time; that's a basic requirement as far as I'm concerned - so I don't follow" . Derek said "as long it will support a complex version of this fine - most reporting tools do not" . Jason said "it'll support triggers" . Derek said "if it supports triggers it will do what im thinking" , but he still wondered if it should be "a separate tool" . Lawyers and medical professionals " need similar as well" Jason said he " really don't see a justification for doing a separate tool - as if a reporting package can't handle that then it needs to be rethunk" . Derek said "im not saying it has to be a spearate package - im just saying if people say that the functionality is stupid and doesnt belong in reports (too specialized) - then we should offere as a separate tool" .

2. GNUe Project Management

21�Mar�2002�-�22�Mar�2002 (4 posts) Archive Link: "Re: Project Management Package?"

Topics: Project Management, DCL

People: Mark Smith,�Gil Hauer,�Ralph Mayer,�Rich Bodo

Continuing Issue�#20, Section�#7� (11�Mar�2002:�GNUe Project Management) , Mark Smith suggested that project resources could be assigned "based on the Human Resources data, if you are using that package also. HR data often includes the skills, qualifications and experience that staff have." This could be extended to record outside contractors as well.

Gil Hauer agreed - "in fact I think that the project management package is very much an integration of other gnue packages: HR, accounting, dcl, etc." He had used Open Plan from Welcom Software, which (although Windows only) "allowed the project manager to assign skill to people/things in the resource pool. It also allowed the project manager to assign a skill to a task rather than a person. During the scheduling phase the project selected the 'best' candidate from the pool that satisfied the skill. 'Best' generally meant 'the most available' I think." .

Mark also noted that "Part of the business of comparing estimates to actuals depends on getting the actual hours into the project management application, which I find isn't well catered for generally. It would be really good if there could be a 'Time and Expenses' module where everyone can enter the hours worked each week on each task within a project. " He had "been hearing the term 'Professional Services Automation' (PSA) used recently to describe this kind of integration of Project Management and other applications, and it would certainly make life easier if it could be achieved." . Gil said "I think that this is where integration with DCL would happen -- activities in the project plan could be bound to work-order entries in DCL where engineers enter hours as well as completion information. I don't know enough about DCL yet though."

However, this was a weak spot with many existing Project Management tools - "I'm stuck right now having to use MS Project in VMware under Linux 'cause it's the only solution" and even that was not ideal. Ralph Mayer said Microsoft Project was "some sort of an "unfinished" software. It can do a lot, but most of the real-world-problems can only be solved useing VB(A). Thats my problem, I am projektmanager, not a VBA-programmer :-)" Rich Bodo said "I always use a spreadsheet. I have managed fairly complex projects in this manner. Most MS tools appear to be designed by comittee."

3. First fruits of the GNUe/DCL merger

21�Mar�2002�Archive Link: "[IRC] 21 Mar 2002"

Topics: DCL

People: Harald Mayer,�Derek Neighbors

Harald Mayer (Harald1) asked "is anything decided about how the merge will be executed? will only the db-structure of dcl stay?" Derek Neighbors (derek) said this was " not fully decided - the first thing you will see is that dcl is getting more external development - as of today some rbac stuff was submitted as a patch - while it might not be the long term direction it solves some important issues immediately - also in the cvs head branch you will notice GNUe Forms (non web screens) for DCL being checked in - the contact management portion will be much much more robust in next DCL - and probably even further extened into real CRM in the GNUe CRM stuff" . If the database structure of DCL did have to change, then "the upgrade path will handle" any changes needed. As well as the GNUe Forms for DCL in CVS, he also had "some others too that arent in cvs that need cleaning up" but which were in his home directory on the GNUe webserver.

4. Electronic Business XML

21�Mar�2002�-�27�Mar�2002�Archive Link: "[IRC] 21 Mar 2002"

People: Sacha Schlegel,�Reinhard M�ller,�Sacha Schlegal,�Derek Neighbors

Talking further about the issues raised in Issue�#7, Section�#9� (12�Dec�2001:�Electronic Business XML) , Sacha Schlegel (SachaS) said that "the openebxml laboratory in sweden has about 5 "scientists" doing projects for and around it. The people have different projects. They are placed between computer science and business. They want to realise business solutions with computer science help." They wanted to model business processes using tools like UML, but also "have executable models. so you model then "save" and "start"." . Reinhard M�ller (reinhard) thought a tool to convert UML to GNUe Application Server Class Definitions would be useful - "that's what we are planning anyway - at least it was my understanding - to have a "designer" for geas - that will work on a high level and save it into xml files and/or database" .

Sacha also mentioned "BPML Business Process Modelling Language (www.bpml.org) " . This allowed you to "model the enterprise business. the next step is inter-enterprise business and there you can model with ebXML (electronic business XML). ebXML focues heavily on inter enterprise business, called collaborations." However, "you need some kind of mapping" between the BPML models of the inside of enterprises and the ebXML models of the inter-relations between enterprises. He was still keen on doing some academic research on some topic around ebXML or enterprise modelling.

The next day (http://www.gnuenterprise.org/irc-logs/gnue-public.log.22Mar2002) , Sacha explained "BPML is a meta language. - basically a xml vocabulary for business processes." He wasn't sure what was meant by "a business process" . Reinhard suggested "an algorithm for the business" . Sacha said "so basically BPML has some tags which people can use to describe their business processes (as mentioned yesterday, mainly for enterprise business processes)" . According to the specification, "A process is a specific ordering of work activities across time and place, with a beginning, an end, and clearly defined inputs and outputs" . He noted " the main entities of the BPML vocabulary are: - messages, - participants, - activites, - rules, -transactions and - processes." However, "I guess there is no software out there yet which "simply" parses it and executes it and voila you have a system which handles your processes." Maybe GNUe would end up as such a system.

Some days later (http://www.gnuenterprise.org/irc-logs/gnue-public.log.27Mar2002) , Sacha apologised for saying in his paper that "there is so much missing" from GNUe at time of writing. Derek thought that was fair comment, but rather than say "its like a car with out a motor - it should read its like a motor w/o a car" . He said "I really really want to get some gnue apps out the door - even if they are not the 'official' n-tier spec." He posted a link to Sacha's article on the GNUe website - "its actually a pretty darn good little research paper - i recommend reading it if you are interested in such glamorous and exciting things as electronic business :)" .

5. Using DCL to report bugs for GNUe

21�Mar�2002�Archive Link: "[IRC] 21 Mar 2002"

Topics: DCL

People: Derek Neighbors,�Harald Meyer

Harald Meyer (Harald1) pointed out that the BUGS file was out of date. Derek Neighbors (dneighbo) said that DCL was now the preferred method of recording bugs for the GNUe project - "soon the bugs file should be generated from there - until then consider the bugs file out of date :)" . There was a guest account on the DCL server (https://dcl.sourceforge.net/dclgw/) , but it was read-only. Soon there would be a gateway so that e-mails sent to the bugs@gnuenterprise.org address would automatically raise a job in DCL. People who intended being active bug loggers could contact Derek for a 'personal' DCL username and password.

6. Using GNUe Forms with Glade

21�Mar�2002�Archive Link: "[IRC] 21 Mar 2002"

Topics: Forms

People: Linas Vepstas,�James Thompson,�Derek Neighbors

Linas Vepstas (linas) asked "anyone here discussing how to use glade to hook up to gnue forms?" James Thompson (jamest) said that the first version of GNUe Forms "was to base on glade code which was a mistake - they have different targets" . Linas said he realised "glade won't run on win or mac, that is not my concern." . With a bit of care, the XML definitions for GNUe Forms could also be compatible with Glade. James asked "so glade would draw the form and gfclient would run it, is that what you are saying?" He didn't see what this would gain. Linas said "I've got to develop a pretty looking glade app; its gotta be pretty or they'll make me code in VB. Ughh. I'm using glade and some custom gtk widgets. Its mostly data-driven: which means most of it is gnue-forms-like - so I'm scratching my head: what's the easiest way from here to there? I could do it from scratch, I could enhance gnue-forms, I could try bond/bonddb" . He said "every half hour I change my mind. The from-scartch approach is to hack some xml that hooks up odbc table.fields to libglade widget names. Should be easy, but ... but it leaves me cold for a long-term strategy (reports, etc.)" . He needed to be able to support a "mxiture of buttons, menus, radio/select, text areas with padding and glitz" . He "also have some custom scrolling strip-chart widgets and a satellite photo map underlay" which he already had working, but "now I have to hook up a bunch of forms to a database thats the easy/hard part - easy but tedious; alternately, hard if I try to merge into gnue :-(" .

Later, Derek Neighbors (dneighbo) said "linas glade support is a WASTE - if you want glade use glade - our designer IMHO is superior to glade at this point and cross platform. i assume your "issues" are either a. lack of 'cool' widget support or b. you desire native gtk. If you want (a) forms really isnt too interested in that, i suggest just using glade. If you desire native gtk simply write a UIgtk.py file. I personally see glade as having nothing to do with forms" . James suggested "you may want to see about mixing and matching, using forms where it saves you time - as designer wizards make that part so easy - but dropping to glade where you need the glitz" . Derek said "a year ago, someone could convince me that perhaps glade could be retrofited to be our designer - but honestly now our designer is there and it 'rocks'(tm) so i cant see going backwards :)" . He continued "if you just want easy databinding in glade - fsthere are lots of projects that are doing databinding for glade - gnome-db being one of them" . James said "it may be possible to extend the forms client to do more ie: support widget plugins, but that's going to take work :)" . Derek said, based on previous discussions, " making gnue MORE complex isnt our goal :)" .

Later, James confirmed "we constantly have to defend keeping the gfd simple :)" Linas said he had had similar issues keeping gnucash under control - "its weird, you want to encourage contributors, so you don't want to piss people off, but its hard to say "don't implement that its a bad idea" without pissing them off - or accidentally specing something thats too grandioise for them to implement." Derek said "im all for contributions - im just saying what you are proposing doesnt make a lot of sense as iirc glade has some databinding capablities or so i hear" . However, "it is of course gpl software and you can do as you like - and we would support you in it unless it was really whacked :)"

7. i18n support in Forms

22�Mar�2002�-�27�Mar�2002�Archive Link: "[Gnue-dev] Re: [gnue-discuss] utf-8?"

Topics: Forms

People: Arturas Kriukovas,�Derek Neighbors,�Dmitry Sorokin,�James Thompson,�ra3vat

Further to Issue�#21, Section�#10� (18�Mar�2002:�International support for GNUe) , Arturas Kriukovas (Arturas) reported on IRC (http://www.gnuenterprise.org/irc-logs/gnue-public.log.22Mar2002) that Dmitry Sorokin (ra3vat) had had even more problems with i18n than he had had when trying to reproduce the bug. Arturas couldn't find "where in forms font is set up?" . Derek Neighbors (dneighbo) suggested "if set anywhere would be gnue.conf" - otherwise "its coming from your theme of either gnome/kde or windowmanager" . Dmitry confirmed that he was receiving i18n e-mails from Arturas, but the GNUe Forms attatchments were showing "as one-byte character string" . Derek confirmed that some documentation he found for wxPython implied "that the THEME font is used" unless over-ridden. He suggested "change your theme to a really ODD and DISTINGUISHING FONT - then open up forms - if it has that same odd font you know its using the theme" . Arturas did so, and confirmed there were "no changes in forms, although kde looked really awfully" .

Arturas said the default enoding in Forms was ASCII, but "if i enforce strings as unicode" then "you'll get nice i18n data" , but it would only display on the form header, not in the data. James Thompson (jamest) confirmed "the font encoding is in UIwxpython" , but "i haven't messed with fonts in forms in a long, long time" .

Derek said his preferred solution would be to set the font "in gnue.conf - allow people to set the font like we do other font options" . Arturas said "i hope adding something like 'encoding="utf8"' should be enough" .

Three days later (http://www.gnuenterprise.org/irc-logs/gnue-public.log.25Mar2002) , Derek confirmed that using _SYSTEM or _DEFAULT instead of _UTF8 "worked here - (ie designer/forms run fine) but i could not test to see if made difference" to the actual display. Arturas said none of these options had made any difference for him, "but i start to believe that's my linux configuration problem" . Dmitry Sorokin (ra3vat) posted a general appeal for people to test some python imports "and give output back here or to my email" to help track the problem down.

The next day (http://www.gnuenterprise.org/irc-logs/gnue-public.log.26Mar2002) , Dmitry got various volunteers to try the python imports for him, and some progress was made.

On the mailing list the next day, he referred back to Issue�#16, Section�#1� (1�Feb�2002:�GNUe unicode support) , and said that although "it would be more dependable someday to have all string represented in unicode and use specific functions to handle them" , in the meantime "str() also _does handle_ strings with chars beyond ascii if desired encoding is provided via setdefaultencoding()" . However, "that function is not available at run time." This could either be fixed by "a. manually changes in PYTHONPATH/site.py" or "b. adding custom module named sitecustomize" . Previously, when GNUe had used python 1.5.2 rather than 2.x, "I was able to run my customized (non-ascii) forms only after adding" specific calls for Russian fonts, similar to what Derek had suggested earlier in the thread. But with python 2.x, "it works without modification when you first provide that getdefaultencoding() gives non 'ascii' in output." He quoted some material from the Dive Into Python (http://diveintopython.org/kgp_unicode.html) website that implied that the sitecustomize.py file determined this. Likewise, www.lemburg.com (http://www.lemburg.com/files/python/unicode-proposal.txt) said that "the default site.py startup module contains disabled optional code which can set the <default encoding> according to the encoding defined by the current locale." He wondered if GNUe could "try to build at least binary snapshot with default encoding set according to the current locale? I did not find how to do required settings after the installation."

8. Bug-testing Designer and Forms

22�Mar�2002�-�23�Mar�2002�Archive Link: "[IRC] 22 Mar 2002"

Topics: Designer, Forms

People: Derek Neighbors,�Harald Meyer,�James Thompson,�Jason Cater,�Daniel Baumann

Harald Meyer (Harald1) reported a crash using GNUe Forms on Windows, using python 2.2. Derek suggested "2.2 you dont want - drop to 2.1 - 2.2 is buggy - you can use it but you wont be able to save forms in designer because of a streamIO bug in unicode support w/ 2.2 (still unfixed even in last candidate release)" , as previously discussed in Issue�#16, Section�#7� (9�Feb�2002:�Occasional unicode problems with Designer) . This meant " if you save them - reopen them - and save them" then a null (^@) character would be inserted "after EVERY character - so you get ^@o^@u^@t^@p^@u^@t^@ like that :) - if you have someone one staff you want to 'joke' with - this is one of thsoe good 'joke' bugs :)" . Some editors wouldn't display the null characters, but "in emacs its visible" . Harald reported he didn't seem to be having this problem, "but if i do save->load it crashes" . Derek suggested "is there way you can install python2.1 on that machine as well? - or better yet just grab the 0.1.1 release - it has all dependencies compiled in so to speak" . James Thompson (jamest) was impressed that Harald had installed GNUe and all the dependancies on Windows from source - "that's cool, most people use the bins" . Derek said that Harald's coolness had already been established, "as he actually submits bug reports :)" . Harald said "my win is mostly unix: apache, mysql, perl, php, xemacs, gcc, ..." Jason Cater (jcater) suggested that Harald was effectively running "GNU/Win ?" . Derek said that "its scary but i hear pretell that Debian/Windows is close via cygwin i.e. apt and much of debian is getting tooled to be usable via cygwin" .

The next day (http://www.gnuenterprise.org/irc-logs/gnue-public.log.23Mar2002) , harald reported " I completed the tests" with different versions of Designer and python - "should I post the complete results to dcl, as there were some more problems with the exe-releases ?" Derek requested "please file the bug - it exists in linux as well - i.e. my current cvs does the exact same thing" . He "loves that we have another bug hunter, i was feeling so lonely" . Harald said that the 0.1.0 "gfdesigner exe release" had several further bugs that the CVS version did not have, and "It seems that the saving bug is even worse. It crashes on other files, too, after one file was saved and closed - but it does not crash, when the first file is not closed" .

Later, Harald asked "which trigger events are implemented, just those from http://www.gnuenterprise.org/docs/techref/x81.html (http://www.gnuenterprise.org/docs/techref/x81.html) or all?" . Derek said "the ones in the techref 'should' be implemented - but these are things that unless one of the developers are using them, probably are not getting properly regression tested" . He suggested for the moment testing or looking at the source code to find out - "(bad answer i know)" . If "you use one that is the tech ref and it doesnt work please file a bug against it"

Two days later (http://www.gnuenterprise.org/irc-logs/gnue-public.log.25Mar2002) , Harald Meyer (Harald1) reported a further bug with Designer, which was happening with the CVS version, but not the official 0.1.1 release - "try making any object in designer, and delete it via the context menu" . Daniel Baumann (chillywilly) updated his version to CVS, and confirmed "it crashed" . Harald said he had "already tracked the bug so far down, that it happens,if LayoutDesigner's OnDelete is called - though it doesn't crash right in there, but sometime later" . Daniel asked "does it crash if you delete a widget a different way?" . Harald said "it doesn't crash if I replace the Destroy() with Show(false) and designer works a expected. Just a waste of resources" .

9. GNUe Application Server APIs

23�Mar�2002�Archive Link: "[IRC] 23 Mar 2002"

Topics: Application Server

People: Reinhard M�ller,�Daniel Baumann

Further to Issue�#21, Section�#13� (19�Mar�2002:�GNUe Application Server version 2 update) , Daniel Baumann (chillywilly) said he was working on some proposals for the GNUe Application Server API. Later, Reinhard M�ller (reinhard) supported this, but added "please make sure we all know what you are talking about" - the API between what and what. He said the "final documentation will be separated by the intended reader - an API doc (for the front end) - and an internal "hacker's guide"" .

10. Testing strategy for GNUe

25�Mar�2002�-�26�Mar�2002 (4 posts) Archive Link: "[Gnue-dev] Testing framework?"

People: Harald Meyer,�Jason Cater,�Derek Neighbors

Harald Meyer asked " Does GnuEnterprise have an overall testing strategy, which describes how a new class has to be tested, before it is added to cvs or to a release?" . Jason Cater said " We do not currently have a formal testing framework for our tools. Well, for that matter, we don't even have an "informal" testing framework. :) " . It would be needed eventually, but " I think we are still a bit early in our development cycle to spend much time on this." . Derek Neighbors said " Yes I generally before a release run a few 'guantlet' forms I have to test functionality. I would like to see this more robust." He had "been investigating several Python testing suites that are general python. I will give a formal report on them soon." He outlined his preferred testing strategy for the short, mid and long term. Jason Cater added "Long term, of course, we really need a more robust, formal testing system. But for the near term, I think our time is better spent on getting good documentation written and improving the robustness of our existing code. I think most would agree."

11. GNUe Reports Output

26�Mar�2002�-�27�Mar�2002 (9 posts) Archive Link: "[Gnue-dev] GNUe Reports Output Markup"

People: Jason Cater,�John Lenton,�Derek Neighbors,�Stan Klein

Jason Cater said that, after the discussions in Issue�#22, Section�#1� (19�Mar�2002:�GNUe Reports proposal) , he had decided to use "XML namespaces in Reports" , and now wanted to discuss "*what* these tags will be :)" .

Jason suggested "The report definition shouldn't contain references to page sizes, etc" , but might "provide *hints* (e.g., this report looks best in a landscape format, etc)" .

He added "I'm thinking in terms of a "logical" formatting markup, similar to HTML, DocBook, or TeX, as opposed to an "absolute" formatting" . This would make it easier to create different types of output from the same source. John Lenton said that using "logical" formatting markup "makes it from hard to impossible to work with preprinted stuff" , and suggested "you should at least allow xpos and ypos attributes, as hints if you want" which the report engine could either ignore or heed depending on the final output format. He also added "raw text" as a suggested output format "For dotmatrix printers printing onto preprinted fanfold" , which were still common for things like invoices. Jason said that "pre-printed stock reports" were "a completely different breed of animal. :)" Derek Neighbors agreed - "Since they are more specialized they should probably be addressed after we have a civil model for normal reporting. :)"

Jason suggested that a wide range of output formats should be supported, including postscript, PDF, HTML, RTF, CSV and TeX/LaTeX. Other formats, such as for specific printers, could be derived from these. Derek suggested supporting output for "say staroffice/excel/word (in native xml format)" . This would be "SOOO much better than exporting to csv then opening in excel." Jason said "Actually, Excel (or at least OpenOffice's scalc) is a *big* need for me. CSV is very limited in it's usefulness. I was just apprehensive about mentioning a non-free file format as a "necessity" :) I included RTF because I figured it'd meet most of the "Word Processor" needs. For the most part, RTF would do everything we need for this class of output. (Or will it? how well are tables supported in RTF?)" . He was "not sure of the practicality of saving the formulas, but having them show up in Excel would rock a few socks." He could use the debugging 'hints' field already in the format to implement this. Derek said " Um in forecasting / staffing and similar situations it just kicks butt. As if you bring over the forumlas opposed to the cacluated number, they can key into the report and have formulated fields calcuated on the fly it might sound dumb but give it to an accountant and expect donuts in the morning. :)" .

Jason also said "I would like to see a generic report "skin", or template" which would apply "site-specific conventions (e.g., paper size, logos, standard header styles, etc)" .Derek said it might be possible to do this either using "'entities' in the .xsl files or use multiple .xsl files." .

Stan Klein suggested supporting "AbiWord native format." He felt "this will probably cover mail merging. It isn't overprinting of pre-printed forms, but covers formatted, templated forms." He suggested GNUe could "Not cast any tags in concrete within GNUe Reports " unless they were necessary for the logic of the application, with as much as possible derived from "a user-definable file of tags." . He thought the initial output parser should output a single standard format "like DocBook with a GNUe Reports DTD that can produce all the other formats. I don't see a need for *developing* a GNUe-Reports-specific output format conversion program. In fact, I think it would be best to use as much as possible of what's out there already before we even consider rolling our own. It might turn out that a minor fix to something already existing would do everything we need. That's the Innovation Commons of Free Software at it's best"

12. Free alternatives to GNUe Reports

26�Mar�2002 (2 posts) Archive Link: "[Gnue-dev] Products similar to Reports?"

People: Jason Cater,�Derek Neighbors

Jason Cater said " While finalizing our output format, I'd like to look at some products with similar goals as GNUe Reports. Does anyone know of competing free/open source implementations?" He was aware of DataVision (http://datavision.sf.net/) and ReportLab (http://www.reportlab.com/) . Derek also mentioned Kugar (http://www.thekompany.com/projects/kugar/) , which used fixed positioning, and did not appear to have a visual designer. " This is now standard in Koffice. It is GPL however."

13. Current status of GNUe

26�Mar�2002�Archive Link: "[IRC] 26 Mar 2002"

Topics: Forms, Designer, Application Server, DCL, Financials (Accounting)

People: Dmitry Sorokin,�Peter Sullivan,�Derek Neighbors,�ra3vat

Dmitry Sorokin (ra3vat) said that the "tools (forms, designer) are useful enough for 2-tier mode" . You could "use designer and then customize them without strong XML knowledge" . The "modules (like accounting, ...) are not ready" , apart from DCL - "they were designed to be used with application server and now application server is in rewrite stage" . Peter Sullivan (psu) said "The team are all volunteers at the moment, so we work w/o deadlines - as no-one can tell how much time they will have" . He said "you can certainly use the GNUe tools in 2-tier to write apps yourself - If you're looking for "shrink-wrap" install and go Financials, HR, etc we're not there yet and to be honest we need to get the n-tier tools written & working before we start there." Dmitry noted that Forms and Designer were available as a "bynary snapshot for MS (it is single .exe to get forms working)" . Peter said "the official release is a few months old, you can either use that - or the nightly CVS snapshots" . For the server end, "for the database back-end, use your choice of database - for the app-server backend, we have an Application Server that a company kindly contributed - but which needs an extensive re-write which is just starting. On databases, we currently support loads of free and non-free choices - including ODBC (i.e. pretty much anything that has an ODBC driver)" . He noted that "Even today, 2-tier is a good framework for those sorts of little projects that you start in MS Access before you realise you actually need something bigger ;-)" .

He confirmed "we are looking at providing mutliple client access, including HTML - there was a guy working on a pure HTML client - not sure where that got to we also had someone working on a PHP client - which I think made more preogress" . However, "In practice, I would expect that using complicated forms via web would be quite painful - so power-users would probably always want to use a proper Forms client - but for occasional users, web is probably fine. Some of our project team are big web-application haters - but if you look at DCL, that is exclusively web-based at the moment - so go figure ;-)"

Later, Derek Neighbors (dneighbo) said "currently we have a framework but not the 'shrink wrap' applications - so you could download and install the framework to use with postgres in probably under 4 hours - on debian if you are experienced linux user w/ postgres running probably take you about 10 minutes" . Although several organisations were using GNUe 'in production,' this was by using "paid consultants or in house staff to write the applicatiosn with the framework as 'custom' applications" . As of time of writing, "if you just want a 'ledger' you might be able to use gnucash or sqlledger - if you want more than that i think gnue is right for you if you are willing to put some work into building what you need" . He said "we are looking for people willing to build/use applications :) - the problem is we ahve limited people resources - and most of the resources are making the tools better - if they stop to build official applications the tools suffer - so we are rough spot - more hands help :) - in fact people that are less engineer and more consulting type are what we need most :)" . He regretted having to keep pointing interested people to other projects - "i really dont want to point you there would MUCH rather have you use gnue - but if it fits your needs better so be it :(" . He was considering building a GNUe front-end to the sql-ledger database structures

Peter said that "the class defintions for GL were fairly simple - could easily be written as normal SQL tables - question is - do we want a 2-tier GL at this point? or does it simply divert us from geas?" Derek said "its a toss up - i for example would say you and i probably really arent really hot on tuning up GEAS - as its not our 'domain'" , so they might as well work on 2-tier applications meanwhile. However, Peter said the "problem to me is that a 2-tier gl doesn't go anywhere - as we scrap it the day we have geas v2 - & a gl w/o ap, ar etc" was probably only of limited use.

14. Argentinian ERP development using GNUe

26�Mar�2002�Archive Link: "[IRC] 26 Mar 2002"

People: Derek Neighbors,�John Lenton,�Jason Cater

Further to Issue�#21, Section�#15� (20�Mar�2002:�Argentinian ERP development using GNUe) , John Lenton (Chipaca) said his team had been working on an Entity Relationship Diagram for their project, and offered to send it via DCC, although it was a work in progress at the moment. Derek Neighbors (dneighbo) suggested "go ahead and send when more complete - glad to see you stopping by - was worried you decided gnue wasnt right tool for the job" . John said "it is, or it will be, we're not sure on that yet :) - if what you advertise on www.gnue.org were correct, we'd be out of a job :)" Derek said "i just encourage you to remember if it doesnt fit exactly - with a little work it probably could :)"

He was thinking "of doing a promotional - free tacos for every gnue commit that gets approved on 'developer days'" , based on some other projects. The reward " would be 'locale' based" , but he was " not sure how we can stream the donuts" . John suggested "you marshall them into XML, of course - that'll be the first GUI DTD" . Derek liked the sound of this. Jason Cater (jcater) said "I love all food" . Derek said "the only kind of food i dont like - is the kind thats not in front of me" .

15. New poll for GNUe website

27�Mar�2002�Archive Link: "[IRC] 27 Mar 2002"

People: Derek Neighbors,�Jason Cater,�Peter Sullivan

After the sucess of the poll mentioned in Issue�#15, Section�#11� (6�Feb�2002:�Polls for web site) , Derek Neighbors asked "actually anyone have an idea for a new poll?" Jason Cater (jcater) suggested "how about "What primary reporting solution does your business use?"" , and gave some possible answers. Peter Sullivan (psu) added a few more. Peter and Jason wondered about adding a ficticious package at the end such as "OLAP-u-like" or "EZ-OLAP :)" . Peter suggested "sorta like the CowboyNeal option on /. (http://www.slashdot.org) polls" . Later, Derek reported "new poll is up" .

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.