GNUe Traffic #45 For 7�Sep�2002

Logo wars - 'I still say we need the savannah gnu in a suit - and he's got a briefcase - that would rawk' - 'black suit and shades - "Saving the earth from the scum of proprietary ERP software"'

This Cousin covers the three main mailing lists for the GNU Enterprise project, gnue, gnue-dev and 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. For more information about the GNU Enterprise project, see their home page at http://www.gnuenterprise.org.

Jeff Childers asked "what do you guys think about standardizing documentation in OpenOffice fileformats?" Brett Schwarz said "Learn DocBook, and then you will know what the advantages are, and probably why they chose it. For large scale documentation, I don't think there is a Word processor that can match it." Christopher Brown pointed to a reference "for quite a number of links about DocBook, including some that won't require that you learn _all_ about DocBook in order to ascertain its merits..." Robert Jenkins "Just found an interesting link covering Windows (and other) versions of Emacs plus psgml and related utilities, Possibly of use for docbook editing??" Alejandro Imass felt that it would be easier to do Docbook editing from within a "Unix or Unix-Like system (BSD, Mandrake GNU/Linux, Debian GNU/HURD, Debian GNU/Linux)" , and suggested that Jeff set up a partition with one of these. He said "BTW you don't really _have_ to use Emacs. There are probably a dozen "strutured" text editors but of everything I've tried (which aren't many) Emacs + PSGML major mode is IMHO by far the best tool for the job." Later, Derek Neighbors suggested that Jeff should look on search engines "for Norman Walsh and you will find the docbook definitive guide on line for free. It is a good book." . For GNU/Linux, he suggested "If you install Debian and have IRC you will get a BOAT LOAD of help. Nearly our whole team runs Debian GNU/Linux and we end up doing a LOT of support for general Debian stuff within our IRC channel. ;)" Kenneth Reiszner noted "For those less talented, JED emmulates emacs with menu in shell."

Jeff thanked Alejandro "for being patient with a new open-source convert. Until recently I was one of the brainwashed masses and have only just had my epiphany within the last six months." He "would scour the offices of Windows entirely if we didn't have a boatload of legacy apps in MS languages to support. Dual-booting on my main is definately an option, one I get closer to every day." He particulary liked "how most of the "open source" "freeware" was cross platformed. After I worked with Python some more I saw how my code could run transparently across all major OS's." This was unlike proprietary development tools "because proprietary OS vendors find their interest in locking up technology" . Daniel Baumann clarified "that GNUe is part of the Free Software Movement which has totally different goals than the Open Source Movement." Derek said "It is also in many circles easiest to say free/open source software to cover bases and political preferences." However, "freeware is very different than free software, and thus freeware should not be used to describe things like GNUe and such."

Earlier, Peter Sullivan noted that "Docbook for GNUe documentation has been probably one of the most, erm, hotly-debated issues in IRC over the past year" , as previously mentioned in several threads, including most recently Issue�#36, Section�#1� (26�Jun�2002:�Documentation standards for GNUe) . "Open Office has been seriously considered, especially since it should be theoretically possible (since Docbook is just another XML format) to get Open Office to save in Docbook format - although no-one seems too convinced about this." Christopher said that he "actually have some code for translating OpenOffice XML output into DocBook that is kind of in the "polishing" stage" but "it's certainly not a two-way translation, and you really only want to be using one source format as the source format." Reinhard M�ller agreed - "I see a danger here: A isn't docbook enabled and writes a document using openoffice.org. B translates the document into the "official docbook format". C makes some changes in the docbook file as he regards that as the "official" source file. >From now on, A isn't able to maintain his own document any more, as the current version is only available as docbook." Jason Cater was more enthusiastic - "It's OpenOffice, Docbook, and, PYTHON!!! :)" - "Now, how cool is that?!?"

Peter also noted that Derek Neighbors had been intending to ask about any WYSIWYG (What You See Is What You Get) Docbook editors at Linux World Expo. Jeorg Lehner said "There is a new genre of WYS* around since a while which is called WYSIWYM" (What You See Is What You Mean) which "I think was perceived and coined by LyX" . He used LyX "for almost any tecnical writing - it is a document Workbench which allows you to preview and export to dvi, ps, pdf, pdflatex, html, latex, plain ascii, and even to user definable formats from any of the above." He noted "It is possible, albeit not trivial to install LyX on Windows." Michelle Lowman said that "A similar tool called Kile also creates TeX files in a graphical environment and can export to dvi, ps, pdf, etc." - "It may be a little easier to use than LyX for someone used to OpenOffice, even if it is a KDE app, which may make it a less than attractive alternative for some.:)" . Stephen Campbell suggested " Texinfo, the GNU documentation file format." He noted "You can generate DVI/PS/PDF with TeX and the ubiquitous texinfo.tex file; Info format, HTML, plain text, or DocBook (!) with the makeinfo program in the distribution. Emacs makes it really easy to generate the navigation." Derek said that Texinfo was a bit archaic compared to DocBook, but that GNUe would willingly take documentation in any format and convert it.

Arturas Kriukovas said that he had managed to "get unicode wxForm via wxPython" by:

Aditya Gilra said that "Unicode encoded as utf-8 has been working for me in wxpython forms and postgresql since forms 0.1. utf-16 has not worked and is not needed either." The two main issues were:

Arturas was surprised, as the documentation he had read implied "that current versions of wxPython do not support unicode" . Aditya agreed that "wxPython does not support unicode but wxWindows 2.3.2 does." As far as he could tell, "utf-8 is simply passed by wxPython as a latin-1 string and wxWindows parses it as Unicode. That's my theory, dunno exactly." . He noted "pygtk2 is much much faster than wxPython, at least startup is. It works on windows too (but without ligaturing, last I'd seen)." Jan Ischebeck said he had "tried to use the pyGTK UIDriver with the latest cvs version of forms and found out that it needs to be changed at many points to get it working." But he thought "it is great to have a bit more choice of UIDrivers." Derek Neighbors asked about the status of Aditya's 2-3 line wxPython patch. He was also grateful "for the native gtk driver" - "I think the LONG term goal was to provide native Qt as well as GTK drivers" . wxWindows had been a pragmatic way of providing a basic, non-native, driver for a number of UIs quickly.

Earlier, Aditya warned that his larger patch to support pygtk2 "was written only for the officially released forms-0.3 version" , as the latest CVS was so "much modified that it broke my pygtk2 driver." People who did not need ligatures would probably find it easier to "go for wxpython driver" as of time of writing. Derek said "I think you will see CVS pinched off for a release ASAP" , in which case this would provide a stable point for someone to re-apply and test Aditya's native PyGTK patch. Later, he asked "I think btami or someone posted they got what arturas checked in working. Can others verify this?"

Jan Ischebeck noted that "the actual setup-cvs.py doesn't work on windows. But it would be great to have something similar, because its a waste of time to build setup executables, if you just want to test the new cvs version of some tool on windows." The main stumbling block was that "windows doesn't support real links ( like ln -s realfile link )" . He proposed a possible solution, but asked "if somebody has a better idea" . Derek Neighbors suggested "Um easiest way is to well, avoid windows. :)"

Bajusz Tam�s felt that "firstrow, notfirstrow are not structural but output tags" and posted a modified demo report to demonstrate this.

On IRC, Jason Cater (jcater) said "originally, I did too - then I realized I couldn't implement grouping without them" . Bajusz (btami) said he had tried processing a modified report without these tags through the Formatted Objects XSL style sheet (fo.xsl), "and it worked well" . Jason said "if you got the same functionality without using the firstRow stuff, I certainly wouldn't mind getting rid of them" .

Bajusz also reported that "i tried my fo.xsl with another grd on a big database, and FOP failed with OutOfMemory exception - what do you think about writing our (GNUe) own formatting engines?" Jason said "I very much want to do that - especially knowing that it gets an out of memory error" otherwise.

After Issue�#44, Section�#7� (26�Aug�2002:�GNUe on linuxfund) , Derek Neighbors explained that the Linux Fund was "a non-profit designed to try to raise money to put in the hands of Free/Open Software projects to help their development. We had discussed submitting for a grant on several occassions but never actually did. By chance someone submitted for a grant on behalf of GNUe and Linux Fund approached me on the validity of the submittal. He strongly encouraged we go ahead and submit. So now we ask please register at Linux Fund and put some penguin pesos to vote for GNU Enterprise. We do not see this as way to 'earn' a living or even cash in on GNUe. We hope that it will afford us to get some better marketing materials printed and get us in more trade shows and possibly seed some merchandise creation so that we can start get funds to do more to support GNUe." There were also other ways to help support GNUe financially, via the Free Software Foundation (FSF) and Affero.

On IRC, Daniel Baumann (chillywilly) urged "you people need to drop all yor linuxfund pesos on GNUe ;)" which was, as of time of writing, 3rd in the rankings. Jason Cater (jcater) reported some problems accessing the site - "I just went to linuxfund.org and I'm logged in as you" . However, "GNUe is #2 now" . It was suggested that you could not assign penguin pesos to a project more than once. Jason said the website said this had now been changed - "Now users can contribute to projects more than once, but are limited to a 1500 per-project maximum still. Users still may not reverse their decisions and un-fund a project." He was not keen on the short description of GNUe on the linuxfund website. It was noted that the short description had been done by the person who originally registered GNUe at linuxfund - the long description had since been changed.

Later, Dan Bethe (dtm) noted that linuxfund got its income from an affinity credit card. It was noted that GNUe were not looking to be too aggressive on fund-raising - there was no intention to use the money to pay people to code on GNUe. Instead, linuxfund money would be used for publicity such as marketing materials and attendance at trade shows such as Linux World Expo, most of which had been paid personally by the core developers up until now. Daniel agreed - "shows and stuff cost money" . He "was just buggin the people in the various channels that I hang out in...no further" to avoid any accusations of spamming or trolling.

Some days later, Peter Sullivan said "hmm guess I should have guessed the LinuxFund.org credit card was an MBNA card in disguise - they are the leaders in affinity credit cards (in UK at least) - /me notes a UK LinuxFund.org card is on the way" . He explained ""affinity" = linked to some other org, usually one that people have some loyalty to - many UK soccer clubs have them - charities too" .

Further to Issue�#44, Section�#3� (22�Aug�2002:�New GNU Enterprise website) , on IRC Derek Neighbors (derek) pointed out some typos, and suggested that the bullet-point description of GNUe on the front page should read:

It is a Meta Project of the GNU Project designed to collect Enterprise software for the GNU system in a single location much like GNOME project collects Desktop software for the GNU project.
It is an application framework
It is applications built with the application framework
A community that ties it all together. :)

Peter Sullivan (psu) said "I think your 1. almost becomes a 0. up front as it encompasses all the others" . He wanted to keep the other three points as they were as "that also matches the tabs across side & on side" .

Later, Jan Ischebeck (siesel) said he had "had a look on the gnue website at gnu.org, and there is still some information about the old appserver in there." It was explained that this site would be replaced with the same pages as the main www.gnuenterprise.org one - this had been one of the aims of the re-design. Jan also asked about "new Documentation like the GComm documentation etc., when can /should it be added to the new website's doc area?" . Peter said that "getting the docs reviewed is a high post-launch priority - for the moment, I have just removed anything obviously outdated" , such as anything relating to the old GEAS application server.

The next day, Peter Sullivan posted an announcement to the mailing list that "GNUe Enterprise are pleased to announce the launch of their new website" . He noted "It's just over a year since we started using phpNuke for the main website. Although this has made adding new content to the site (in the form of news stories) much easier, it has caused some other problems" . He felt "We would continue to recommend the free version of phpNuke (or, if you're starting today, probably the free fork Postnuke) for anyone who needs a free software solution for a fully-dynamic, database-driven, news-orientated web site. We've just come to realise that we do not ;-) The new web site is intended to be a much simpler site, both for users to navigate and for us to maintain and administer."

Some days later, Peter noted "all the logs for Aug (whilst bigbrother was on vacation) are now back on website at the usual location - all we have to do now is get them sorting properly again ;-)" . Andrew Mitchell (ajmitch) asked about the future of the www.gnu.org/projects/gnue website. Peter explained "the aim is for www.gnu.org to have same content as www.gnuenterprise.org. I am just sorting out the technical details at moment - awaiting response from gnu webmasters - but the intent is for two to be the same - as we don;t have time/inclination/need to do two sites" . The GNU webmasters needed to decide "in terms of the overall conceptual map of www.gnu.org, should we be /projects/gnue" (where the existing site was) "or /software/gnue" (where GNUe's HTML CVS in Savannah was mapped to).

Andrew said that "you will need to have no absolute links, i think to have it working on both www.gnuenterprise.org & www.gnu.org" . Peter agreed - he had written the new site with www.gnu.org guidelines in mind. "One thing I haven't done yet is go thru' old news items and check there are no links to non-free s/w as per FSF guidelines - which we shouldn't really be doing anyway - as we are, when it comes down to it, a GNU project" .

Later, Dan Bethe (dtm) asked "FSF wants web sites to not _link_ to non-free sofwtare? that's insane." GNU had made extensive use of non-free software, if only "to learn how to make a free software equivalent" - "they _had_ to" . He asked if "now that the founders are done with the parts they think are interesting, such as gcc, emacs, etc... they can keep their nose in their book and tell people to be oblivious to the outside world?" Andrew said "it's about not recommending non-free software to people, because at this time we have a wealth of free alternatives" . Dan felt "for the stuff that the members of the FSF are personally interested in, yes :)" - but not necessarily in all areas of software. Peter said "try looking at any proprietary s/w vendor website for links to the "opposition" (whether other prop. or free). Free s/w can afford to be more catholic and talk about other free s/w - but there's no reason why we should do the prop. boys' work for them. There are plenty of other places on the web to find out about prop s/w" .

John Lenton (Chipaca) asked "is there any way to estimate when the papo patches will make it into gnue?" and "is there anything _wrong_ with the papo patches?" He noted that the patches for GTK2 had been applied very quickly, as discussed in Issue�#44, Section�#8� (26�Aug�2002:�wxGTK2 driver for Forms) . Peter Sullivan (psu) said "I know that several of the core people are mega-busy at the moment which is probably the main cause" - the GTK patch "went in quickly because it's Arturas' area, and he was able to look at it quickly & patch it in as it only affected one UI driver for one tool (Forms). From what I can gather, the papo stuff is far more wide-ranging" .

John asked "how hard would cvs access be?" Peter said that "most people don't get CVS access from 1st patch - I think this is a legacy from early days when people would get CVS access and disappear BUT a) papo is different, becuase you are doing this professionally - b) As per previous discussions, I know Derek would rather you were putting patches in the main CVS rather than your own anyway" . John agreed, saying "it is because of our diverging cvs that we get more and more anxious" .

Peter said that GNUe needed "to decide how to handle CVS" now that it was reaching critical mass - either make CVS access more widespread or "switch to the other extreme and have Linus-like "colonels" for each part of the product who review all patches in their area and are the only ones w/CVS access - but with the implication that they have to have the time to commit (no pun intended) to this" . James Thompson (jamest) noted "i don't have a clue what patches are outstanding, what's been submitted, who has cvs and who doesn't and I'm supposidly a coordinator :( - so it's nothing personal" . It was suggested that all of papo's patches should be rolled together and applied blind if people did not have time to review them. Peter felt "IMHO, a patch from papo is almost as safe as from" the core developers, as like them, papo used the tools themselves on a daily basis - "and they hang out here and talk to us, so know why we do some things the way we do - even if they don't agree ;-)" However, it was noted that breaking CVS head was not necessarily a problem anyway. John asked "is there a way to grant write access to only one branch of cvs?" This was being looked into as of time of writing.

Karlis Peisenieks (karlis) asked "why wasn' lisp used for gnue?" Peter Sullivan (psu) said "I've seen "Why not C/C++/java loads of times, but never lisp" but "given it's reputation as an AI lang I guess it could be a good lang for writing business rules in" . He said that "The intent is that some day AppServer should support multiple langs for triggers/business logic etc - These will be abstracted in the same way as the database and RPC via GNUe Common. Hence, as long as someone can write a "wrapper" for LISP to speak to the python code base of AppServer then yes, we will support LISP" or any other languague. Daniel Baumann (chillywilly) said "the trigger system will support multiple language and appserver will use it just as forms does now, iirc" . Karlis said that "for triggers it should be easy, object tree has to be represented somehow" . Daniel said "it is represented in xml as a GObject in common" . Karlis said that this was fine, "but to have "full" control in other lang, not just function set(path, value), get(path) - all tree has to be made "native" imho" .

Peter said that Application Server was the key to the GNUe project as of time of writing, "as we have held off doing packages (Financials, HR, etc) until we have a reasonable appserver to base them on. There's no reason per se why we couldn't write a Finance package in Forms in 2-tier (forms talks to d/b) - but that's *so* 20th century... The fashion these days is n-tier (forms to appserver to db)" . There had been an initial, proof-of-concept, release of the new Application Server in July. He explained "a simple example of biz logic would be that the lines on an invoice must add to the invoice header total. In 2-tier, you'd have an on-submit trigger to check this & throw a "fix it bozo" msg to user if wrong. In n-tier, this checking sits in appserver as a very simple biz rule. Obviously, biz rules can be much more complex than this - and may involve workflow-style processes e.g. balanced invoice goes to Fred for approval - but that's the basic idea AFAIK" . Karlis deduced "aha, and this way gnue application will consist of related form and report definitions and business logic written for appserver" .

Derek Neighbors (derek) said GNUe was not written in LISP as "LISP is NOT a business programmers language END of STORY" . He added "btw: we DO support lisp - well scheme - our appserver/forms have a pl ugable business rules engine architecture where by anyone wishing to fashion a plugin engine for their language can" . The "current appserver only supports python - but it is in the specification to have exposed api where as you can use any language you like - even Visual Basic or such" . This had been discussed in detail with Richard Stallman (rms). Also, python was better for cross-platform support than LISP - "python + wxwindows gave us win32, *nix, mac out of box" . However, this had caused the FSF some problems "because there was brief time that python had issues" with licensing, but this had been resolved with Guido van Rossum (guido), the author of python. Some initial prototyping work on Forms, and the original version of GNUe Application Server (GNUe) had been written in C, "and at one point we were going to try scheme/lisp" but the issues at that stage were "a. horrid documentation" and "b. no good toolkit support for doing xplatform UI (even weak single platform support)" . However, this had probably changed in the 4 years since GNUe had started. Karlis asked "was rms for lisp or against python?" Derek said "a little of both. Mostly for lisp i think. It was odd as we were the ones originally concerned with python once it was in licensing limbo - so we approached rms to talk with guido. It was then sometime later that he came back and asked why not lisp (after python was fixed) - or at least thats how i seem to remember it" .

Further to Issue�#43, Section�#9� (15�Aug�2002:�Point of Sale (POS) systems) , Jason Cater (jcater) said "the options for free POS systems really sucks" - "and I can't find a python one anywhere" . Andrew Mitchell (ajmitch) suggested "so it's hack-your-own time?" , but Jason was not keen. He was "perusing the source code of all 3" which he had found "and seeing which will be easiest to mangle - /me wants to hack whichever one I use to use GNUe as backend" . The three systems he was looking at were:

He noted "L'ane and BananaHead are GPL - gibbon is LGPL" . He reported problems getting BananaHead to compile - there were no Debian packages for any of these POS systems. Derek Neighbors (derek) noted two other alternatives - easypos and gshop, both of whom had "said they want to work with gnue" . He suggested "you take the table structures and make gnue screens for them" . Jason said he "doesn't foresee GNUe Forms being suitable for a register front end for some time (if ever) - because a "cash register" type entry screen is highly specialized imho - it would take some hacking to get GNUe Forms to be less "generalized"" . He noted that both of Derek's suggestions were written in C, and "easyPOS keeps all its data in text files - no database backend" . Also, "gshop hasn't released anything for 2 1/2 years - and easyPOS for almost 2 yrs" .

After midnight, Jason noted that "the ones with the most backing are java based - which of course I don't intend to run" . Nick Rusnov (nickr) said that "people don't realize that Python has superior cross-platform" . Jason noted "from what I can tell, the gshop programmers have gone to easyPOS (for whatever reason) - easyPOS has no database and therefore no schema" which might make working with GNUe difficult. Nick noted "well there still may be a 'schema' even without a 'real' database" . Jason said "when I say "flat text file" I don't mean fixed length records or CSV - it's really weird" .

Wouter de Vries (kermy) said he "will be developing a document management system with 4 other students. i was wondering wether you could give me some pointers." Derek Neighbors (derek) asked "woudl you be willing to do the dms under the GPL as part of GNUe?" Nick Rusnov (nickr) "was going to do our document management stuff but he has been busy" - as of time of writing, "for the document management stuff (i.e. docustore) only the document exists" . Wouter noted "i see you use python extensively in the GNUe project. we will be using C or maybe C++. will that be a problem?" Derek said not - "but of course we think you would be better off using python - you will get a LOT more help from us and will have gnue common at your disposal. Your development time will be about 100% faster (and thats if you dont know python yet) ;) i.e. all gnue developers were pretty much C developers before gnue - BUT again certainly if you feel you must use C you can" . On performance, "i will make bet with you if you do it in python you wont be dissastified with performance - 95% of the time C apps are slower than python ones" . The main exception was Zope, which "is a web application and web applications in general are slow and sucky" . Wouter said he would "discuss the whole python idea with the others."

Charles Rouzer (Mr_You) opinioned "we need more developers for a usable appserver" . Daniel Baumann (chillywilly) said that Jan Ischebeck "and I are doing our best - I am working on it right now in fact" . They were more than willing for others to help out. Charles asked if "appserver connections are in plain text?" Daniel said that "appserver connections are exported via grpc - it's an xml file" . "The one thing that works right now is xmlrpc - which can be over http possibly https" . He explained "forms talks to appserver via a driver which makes rpc calls" to the Application Server - "the driver looks just like any of the other db drivers" from Forms' point of view, although it did not "handle introspection so you can't use designer to hook them up right now" . Hans Kugler (LuftHans) said that connections to the Application Server "should be encryptable. /me runs almost everything over https and ssh tunnels other things." Daniel said "yea, so you could run appserver in an ssh tunnel" .

Later, Andrew Mitchell (ajmitch) asked "how far along is appserver? when can i use it in production?" Daniel said that, as of time of writing, "it doesn't do much but let you traverse records in a db" . However, "there's more code in _featuretest that jan added" and "I am trying to finish the parser for the object format right now - still ;) Actally jan has code to play with records and such and even execte python code stored in a db" . He pointed to the README "in gnue/appserver/src/_featuretest" for more information, noting "the stuff in _featuretest is functional - you can setup the sample db, then run his test program" .

Charles Rouzer (Mr_You) asked "does GNUe allow you to show partial text, like a CC or social security # for example?" . Jason Cater (jcater) said he was "implementing input masks" which "provide a means to do that - /me hadn't thought about using them that way - but it's a good idea" . Daniel Baumann (chillywilly) suggested that input masks could be used to "specify the format of the input and they have to enter it like that - like for SSN they have to enter all digits from 0-9 and it puts dahses in automagically for example" . Charles said what he was looking for was more "output masks" . Daniel suggested "you could just call it a "format mask" and be generic about it I suppose" . Jason confirmed "you can define separate input masks and display masks for any field" .

Daniel Baumann (chillywilly) continued "writing a parser" for objects in the new Application Server, trying to re-use much of the XML parser code in GNUe Common which was already used by Forms, Reports and Designer. He asked whether "Gtypecast basically casts the xml tag info into appropriate "objects"?" Jason Cater (jcater) said "it converts the xml attributes, which are always stored as strings, to the appropriate datatypes" - "a string, or a float, or whatever is needed" . This meant that the attribute name "is expected to be A-Za-z_- or such - i.e., representable in the python namespace" . He confirmed that "text is just returned unprocessed" .

Daniel asked "if I have a tag that is the root of the docment but this can also be nested (i.e., nested modules) I can just set SingleInstance to 0?" Jason said "I also think there's a UsableBySiblings or something like that - that should be set" . Daniel also asked "in the schema parser what do you use GSObject for? I know it is like the parent of the heirarchy bt why did you write it?" Jason said "it's there in case I need to add functionality in the future - with forms and reports, we didn't have that common class - but needed it later on and regretted having to change all the code :) Just consider it planning ahead, although it is useless now" . He also confirmed (after some prompting) that GObjects supported triggers. Daniel wondered "what do I say is the parent of my GObj if it can only somtimes have a parent?" before noticing "oh wait that's a defalt" argument he could use for this.

The next day, Daniel asked "what was that option to Attributes dict in the parser dict for allwing the top level element to be a child of some other element sometimes? ;)" Jason said "um, actually I think I told you wrong - will the element only be a top-level element OR an element of a specific tag? i.e., it's not like <b> in html where it can be a child of almost anything? if that's the case, then I think the logical thing to do is set ParentTags: (None,'theOtherTag')" . Daniel confirmed it would be a "nested tag" . Jason suggested "you might want to look at common/src/GConditions.py and see how I handle nested "ands", "ors" etc" . Daniel said that the XML he was trying to parse had "a <spec> can contain <definition> which can contain a <module< which can contain a <spec>....nested" . Jason said "so I think you want to set spec's ParentTag to (None, 'module')" . Daniel explained "spec just allows for no containing module - so things are in the "default" module" . Jason agreed - "that at least looks logical" .

The next day, Daniel asked "is there any documentation the xmlElements parser dict?" Jason replied "the code" . Daniel said he was starting "a parser for the ODL xml format" . He asked why GNUe did not use "xml.dom? - I think that lives in pyxml and/or xml.minidom" . Jason said "many reasons" , including "dom requires you to load the entire thing into memory before using - which could become a biggie for really big projects" . He was "more an event-driven guy - not a tree-driven one" . Daniel asked "aren't you building your own tree?" . Jason agreed, "but we do more than that" . It also provided "default values, initialization, conversion from old, deprecated formats to current format, importing - oh, and all Designer needs is that dictionary to be able to support the basics of a product - that was the biggie as I don't want to have to code a product twice - once for the actual runtime and once for the designer module. That's why I cringe everytime I hear "why not use DTD instead of the GFParser.py dictionary?" - um, because our dictionary is doing more than parsing XML :)" Daniel said he did not "want to make life harde fr designer - but I figure appserver will have an metaobject api (operations to add classes, methods to existing classes, etc.) and/or you can modify the xml files directly" . Jason was "cornfused - as I didn't think we were starting out w/ODL" . Daniel said that the old .gcd (GNUe Class Definition) files were basically "IDL + some stuff wanting to be ODL - ODL == IDL + classes, attributes, relationships, and collections" .

Later, Daniel noted that "IDL was used in making corba interfaces to the" previous version of GNUe Application Server (GEAS) - "imho, corba was the old geas's problem and the fact it was writtin in C did not help with intergration with existing code" . Given that "DOM is just an API" , "I have no reason to use DOM - would require parsing a tree twice - waste of time" . Nick Rusnov (nickr) said he liked "DOM better than SAX" . Daniel said "yes, but the way the gnue tools works is you don't have to create a DOM tree representing xml and then create a tree of objects that access the other code like the rpc stuff, the db layer, etc. - thus we can also use the SAX parser to create metaobjects straight from the xml for the appserver" . Nick suggested "you could use DOM internally for the objects :)" Daniel said "we create a tree of GObjs directly so they are like an internal DOM" . Nick agreed that "sax is good if your object model isn't much like the XML tree, or you don't want to deal with the overhead in your model" , but as Daniel pointed out "ours is exactly like an xml tree" - "at least from what I am told" . Nick said "well why not use dom then - serialization and loading is trivial then" ?

Hans Kugler (LuftHans) was having problems setting up NOLA. Derek Neighbors (dneighbo) asked "you running acclite or nola? /me only has dealt with acclite" . He explained, further to Issue�#42, Section�#8� (11�Aug�2002:�acclite and NOLA) and previous threads, that acclite was a "custom nola (er fixed)" that used "postgres" rather than MySQL. Anonymous CVS access had not been set up yet, but snapshots of the code were available. He explained "we couldnt stand the tree structure and mysql of NOLA as well as other minor issues - so jcater fixed it up and we inserted in our cvs as acclite - and made work with postgres and such" . Micah Yoder (micahy) "has been doing fixes against it and converting to GNUe Framework. The idea is when properly tested we will offer back to noguska team to merge with their NOLA. If they accept it acclite disappears. If they dont accept it, acclite becomes a NOLA fork" . Hans said "I just need something that works as I have to bill people tomorrow" . Derek suggested that, with such a short timescale, "i would just open up openoffice and do an invoice" in the word processor "and print it out so you can get paid - then put focus on getting NOLA or SQL*Ledger or similar working" . Hans said he already had "an invoice program I wrote that gpg signs plain text and emails it off, but I need to start using a real system sometime."

Marcos Dione (StyXman) asked "if there's a way to disable widgets... uh, I need it @ run time." . Jason Cater (jcater) said "there's a read-only flag - other than that, not really" .

Marcos said "we need to get to the widget's vales." He had worked out some code to do this in a trigger, but he felt it was very inelegant. He asked "if I add a __getitem__ method to gfdatasource, anyone would complain? it would return a item from GFDataSource._object._currentResultSet._cachedRecords" . Jason originally suggested "why not use getRecord?" before realising "a datasource does not hold data - you must have a result set - and it has the getRecord iirc" He agredd that "a GFDataSource.getCurrentResultSet might make sense" . Marcos volunteered to submit a patch. Jason asked Marcos to send it to info@gnue.org, as the *-support@gnuenterprise.org addresses that linked directly to DCL were not "up and running yet :( (since our migration)" .

Further to Issue�#44, Section�#3� (22�Aug�2002:�New GNU Enterprise website) , Bajusz Tam�s (btami) asked for "any news about" restoring GNUe's own DCL (Double Chocco Latte) install. This was used for bug and task tracking within the project. Peter Sullivan (psu) said "I know there were some tech problems, because of conflicts between restoring backup and moving to new (dneighbo-security-patch) version" . He missed having "DCL, too - I'm having to use TODO.txt files or even (yuk) paper to list things" . Reinhard M�ller (reinhard) said "paper? isn't that a classic optical WORM device?" Peter replied "yep, quite a good one actually - Random access, refresh cycle of up to 100 years & no need for non-free reader software ;-)"

Dan Bethe (dtm) pointed to "a good set of discussions and definitions on the meaning of "enterprise class"." He also found "Enterprise Linux Today" interesting. Derek Neighbors (dnSleep) noted "i have sent articles to eltoday before and i think some were even published - all our press releases go there as well" .

Sacha Schlegel (SachaS) asked "are the gnue dependencies fine with python2.2?" Jan Ischebeck (siesel) said "there is a problem with the wxpython package, which only exist for python 2.1 at the moment" . He had resolved this by using the --force-depends flag to tell Debian not to worry about the different python version numbers, which had worked - trying "to build wxpython from source" had not. Jan and Sacha confirmed that the Debian packages needed for GNUe were:

Sacha reported that, once the dependencies were all installed, installing GNUe itself was "a breeze - gnue-designer runs! Congratulations. Damn you are good!"

Jan Ischebeck (siesel) asked "I have a list of entries and I want to press a button fill the list with records" . James Thompson (jamest) clarified "the button performs a query on the form w/ specific values in the query mask?" Jan said yes, "But the button should build the query mask. not the user" . James said "are you going to have multiple buttons each w/ different query....if not queryDefault attrib on entry fields may get you want you want - if that isn't the case we'll need to add trigger functions for putting the form in query mode and executing the query, probably to the form object - i don't think it'll be hard to do" . Ariel Cal� (ariel_) noted "this issue of updating a query (i.e. a dropdown list) was previosly discussed with derek and others" , including in Issue�#35, Section�#8� (24�Jun�2002:�Foreign Key drop-down boxes) - it "is a feature that also the guys of papo are waiting for" .

Further to Issue�#43, Section�#12� (18�Aug�2002:�GNUe at open source e-Government conference) , Stan Klein reported that "We didn't get selected to speak or demo at the e-government conference. I still think we should submit material for the "conference manual". However, they are having a Federal, state, and local e-govt conference next March. Perhaps we should target that one."

�
Kernel Traffic Latest�\|�Archives�\|�People�\|�Topics	Wine Latest�\|�Archives�\|�People�\|�Topics	GNUe Latest�\|�Archives�\|�People�\|�Topics
Czech

1.	21�Aug�2002�-�29�Aug�2002	(20 posts)	Documentation formats and tools for GNUe
2.	23�Aug�2002�-�29�Aug�2002	(9 posts)	Forms i18n support in wxPython and pyGTK
3.	23�Aug�2002�-�29�Aug�2002	(2 posts)	Setting up CVS versions of GNUe on Microsoft Windows
4.	26�Aug�2002�-�1�Sep�2002	(1 post)	Producing FO (Formatted Objects) output from GNUe Reports
5.	29�Aug�2002�-�1�Sep�2002	(1 post)	GNUe on linuxfund.org
6.	28�Aug�2002�-�30�Aug�2002		New GNU Enterprise website
7.	28�Aug�2002		Patches from papo and CVS access policy
8.	30�Aug�2002		GNUe and Lisp
9.	30�Aug�2002�-�31�Aug�2002		Point of Sale (POS) systems for GNUe
10.	31�Aug�2002		Document Management Systems and GNUe
11.	31�Aug�2002		Status of Application Server and security
12.	31�Aug�2002		Input and Output Format Masks
13.	1�Sep�2002		Using the Common XML parser in Application Server
14.	2�Sep�2002		acclite and NOLA
15.	2�Sep�2002		Getting widget values from within Forms
16.	3�Sep�2002		DCL for GNUe project
17.	3�Sep�2002		What is Enterprise Class?
18.	3�Sep�2002		GNUe dependencies in Debian GNU/Linux
19.	3�Sep�2002		Using triggers to run queries with different query masks
20.	4�Sep�2002	(1 post)	GNUe at open source e-Government conference

GNUe Traffic #45 For 7�Sep�2002

By Peter Sullivan