GNUe Traffic #8 For 22�Dec�2001

Appalling pun of the week: "Just a hint for all you guys: don't shake up the hot sauce bottle unless you are fairly sure the lid is on it" "Just shows how dangerous open sauce is as opposed to closed sauce"

It also covers, on an intermittant basis (i.e. when I have time), the #gnuenterprise IRC channel. A great deal of development discussion is still going 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/) .

Further to Issue�#6, Section�#4� (30�Nov�2001:�Revised Website text for Overview of GNUe) , Derek Neighbors said that licensing was an issue in determining friendly/unfriendly packages. Based on his original discussions with Richard Stallman, the categories would be:

Preferred: Is GPL and meets our standards.
Friendly: Is Free Software other than GPL and meets our standards.
UnFriendly: Is Free Software of any kind that doesnt meet our standards.

Derek Neighbors commented on "section 2.1.7 Business Object Definitions..." . He wasn't sure how to handle re-hires. Mark Smith felt "it would be good to make the re-hire process as streamlined as possible, avoiding rekeying of data wherever possible." Derek agreed.

Derek also asked what a 'post' was in this context. Mark explained "Post equals jobcode/title" but he was open to better terminology here. He explained "Job data (Job Title, Job Hours, Job Minimum Qualifications, etc) can exist independently of the employee, as when a job is vacant." However, smaller organisations might not have formal posts - "They would prefer just to give a person/contract a job title, and leave it at that." However, allowing for both ways of working meant "the same data (e.g. job title) could be held in two different Classes, the Contract and the Job" . Derek suggested "I think the right way to do it woudl be to have the person and the job be separate, but in the template for a smaller company we make the information for postion/employee all be on one screen so they dont 'think' they are putting in different classes. This way if they grow and decide to change their mind they arent redoing data structures, but rather just using different forms."

Mark wondered if "the best way to get a clear overview is to draft out the key Classes in the whole package at once, rather than try a module by module approach" Derek said "I think the current approach is ok. We have 'base' classes that are really used if you have things that are spanning across multiple packages like person class. I do wonder if we might need package bases as well" as the overall GNUe base module.

Derek had initially suggested that "Details from former employment should include pay information, possibly for several previous employers." Mark explained "My understanding is that Payroll will definitely want pay info from the last job, especially total tax paid this tax year" , but probably not back beyond that. Derek said "At least in the states this is not a requirement."

Todd Boyle asked "Will GNUE HR interfaces or data model converge with hr-xml (http://www.hr-xml.org/channels/home.htm) information structures?" Derek said "Just like ebXML and ALL other standards GNUe can/will conform." Personally, he thought "datastorage via xml is a bad idea, but we already today in (reporter) and later in integrator will have means to set a fixed mapping output to virtually anything, including XML."

Derek also initially thought "things like relationship/status etc" should be immediately after the class that referenced them - "That or make better comments for them. :)" . Neil Tiffin said "The original parser required them first" but he thought this was no longer the case. Reinhard M�ller disagreed, saying "Before you can reference something, you have to define what it is." Neil asked about circular references. Reinhard said "We will be able to do this. However, I would guess that most of the circular references are merely a workaround for missing features in the geas interface" . Derek said "My major point was to avoid confusion, regardless of processing order, if we just put in the comments what classes used it, perhaps that would be sufficient." After giving an example, he said "In fact, if we made these type of headers 'standard', we could then create a doc tool, that built 'docs' off a gcd, that had links to what is used by what, etc etc etc..."

Further to Issue�#7, Section�#3� (10�Dec�2001:�Segmentation faults with GNUe Application Server) , Reinhard M�ller (reinhard) said "i fixed your geas segfault" , which had, as expected, been to do with trying to execute empty queries. He added "btw geas still doesn't do any meaningful when executing an empty query - just it survives now" .

Jason Pattie (pattieja) was having problems with the Python dependancy for GNUe Forms. James Thompson (jamest) said that GNUe Forms needed a specific version of Python. Derek Neighbors (dneighbo) said "we created an 'ugly' but good dependency in moving to pyhton > 2.0" . If you already had python 1.x, "then when installing things invariably they go in wrong places :) - i solved this on red hat by just instalilng everything from source" using the "actual tarballs - though you SHOULDNT have to do that" . There was some general discussion about the relative merits of Red Hat rpm and Debian apt-get. James said he had "installed as may python requirements as binary - then the last few things missing as source" .

Four days later (http://www.gnuenterprise.org/irc-logs/gnue-public.log.17Dec2001) , Phil Cole (fil_c) asked "Could Python2 use Python-1.5 PyXML libs?" James Thompson (jamest) said "you could copy the precompiled files but you'll get lots of warnings about differences in the API IIRC" Derek Neighbors (dneighbo) suggested "i would grab pyxml tar from sourceforge" , as Red Hat RPMs for python were not very stable at the time of writing, "as python is in a state of moving from 1.5.2 to 2.x as official" release within Red Hat - there had been similar issues with Debian the previous month. Phil went "off to sourceforge" . Derek said "i REALLY apologize for the inconvience, i know it 'pisses me off' when stuff has dependencies or is a pain to install - we made the choice to go python 2.x because it brought us some much desired functionality and we dont expect gnue to ship with any distros until 1.5.2 has been moved and 2.x replaces in the distro's anyhow - 'unfortunately' it means a little rougher first time experience in the interim :(" He normally did the RedHat testing, but had actually upgraded python to 2.x by using source code. He felt often RedHat rpms tended to ask for unecessary upgrades - "they 'try' to understand 'dependencies' but what they really mean are what was on the 'authors' machine" . He said "believe me the long term of GNUe is that no one has to fight like this to install things :) - the windows installer is a good example of this - i think my 3 year old might be able to handle the windows install" . He said that the setup.py file "bitches hey python 2.x isnt installed" , but could be made more sophisticated and check other possible python problems. Jason Cater (jcater) said "the whole thing needs reworking and I've started some stuff wrt that"

Daniel Baumann (chillywilly) said free software did not have to be non-commercial - "I think some ppl plan on selling GNUe solutions " . Peter Sullivan (psu) said GNUe's motto could be "we don't sell software, we sell solutions" but felt that "sounds awfully like a prop ERP vendor's tagline - except that a GNUe consultant actually means it..." Ulrich Ech (jack-e) said "i like the idea to share work on the basics (gnue for example) but i cannot see any way to keep on my business if i cannot sell an app that is build on these basics .." Charles Rouzer (Mr_You) said "I believe any/every company has a right to charge for their work for compensation (people gots ta eat), but greatly appreciate those companies that "free" their software after reasonable compensation." He added " I believe you will find higher profits focusing on services versus a packaged product - software is and should be a commodity" James Thompson (jamest) said the way he worked was that "they get a cut rate as long as anything I do for them goes back to gnue [...] so lots of work I do in forms that's generic doesn't cost them a dime - however screens created in forms that they use they are charged for" .

Ulrich explained he was planning to use GNUe for an Account Management package, and asked "can i sell this app (giving sources to my customers .. python won't let me another choice) to a number of companies ????" He was willing to contribute back things that could be usefully generically like "the sapdb-driver" and enhancements to GNUe Common. Jason Cater (jcater) said, based on how Ulrich had described it, "AFAIK, all that is within the bounds of GPL wrt GNUe" but pointed out that GNUe was looking at Account Management too - "I'm not saying "Don't do it"... I'm just making sure you are aware that we will do similar stuff"

James said "i see no problem with you making "closed" .gfd and .gcd files" - people could even "modify our parsers to only accept digitally encrypted/signed gfd files and donate that code back [...] then you could distribute encrypted/closed gfd's that your customer couldn't read via normal means" . Charles clarified "any modification of source code must follow GPL, applications written using GNUe Designer (.gfd, .gcd) can have their own license and be commercial/proprietary if you want" .

James Thompson (jamest) confirmed that "the UI rewrite is underway" for GNUe Forms. However, he was trying to keep it simple - "I really don't want to see a widgetfest in forms" . He said "one of my major complaints about widget sets is that 20% of what they give you can do 80% of your needs" . The rest just increased complexity and encouraged designers to play. So he wanted "to keep the forms UI lean and very focused on making data aware apps very very easy to write" . Ulrich Ech (jack-e) suggested "but perhaps one could write forms it in a way that the it is easy to include into more "advanced" applications than just data-in/output ..." . James said he wouldn't object to this, "I'm just saying that we'll (hopefully) keep the focus on making the basic business tasks (writing interfaces to get data into the system) very very easy and the other stuff may make you work a bit harder" . Even as of writing, "you can make a forms trigger do anything python can do" . Another benefit of "keeping the UI simple - the same file worked seemlessly on text and gui platforms" and "with madlockes work with html clients we'll soon (hopefully) have a web interface as well" , all using the same forms definitions.

Charles Rouzer (Mr_You) asked "does anyone have any problems with storing GNUe definition files inside a database?" . This would help security. Derek Neighbors (dneighbo) said he personally wasn't keen. "i think we all agreed that would be an 'option' - perhaps even the default - but we would never remove the ability to have .gfd, .gcd, etc be files" . He felt having them as files made remote maintenance via a secure shell much easier "when im on the beach in hawaii" . Charles said he thought in any case "that password encryption of the GEAS user's password inside the geas config file should be encryptable [...] thats your first line of defense against a box that has been rooted" . Neil Tiffin agreed, and asked Charles to " send some code" .

change objectstore and oql into a reusable database abstraction library
enable calculated fields
make the whole thing thread-safe
store object definitions in the database instead of gcd files
implement multi company
implement a security concept
database fault tolerance
transaction support
load balancing
database access monitoring (logging of all db operations)
administration tool (provide number of users etc. and some administrative operations as pseudo-businessobjects)
be able to point object field defaults to a company parameter list or defaults located in the GEAS.conf file.
add MySQL support to parse_load_sql.py
add Oracle support to GEAS
abstract CORBA/client support to enable using different ORBs or other network connection technologies
add support for omniORB for windows compatibility

Stuart Quimby (ToyMan) asked "anybody here use the zope cmf stuff much?" He said "i REALLY need a content mngmnt interface" , but tools like "phpnuke and postnuke and, OpenACS" looked "pretty functional 'out of the box'" but not particularly extensible. Derek Neighbors (dneighbo) asked "you plan on doing ecommerce on this thing too?" He had been looking for an e-commerce partner for GNUe, and had looked at zope, which "fits the 'python' mold" but didn't seem to have much substance to it. James Thompson (jamest) suggested "midgard" . Derek said "they were looking at maybe working with us at one time" . GNUe needed a partner for :

portal tool kit (for intranet things)
content management (for internet marketing type stuff)
ecommerce store front (extension of 2 for products)

Jason Cater (jcater) said "I'd say content management is 70% workflow and workflow is important to us so it might be a natural extension" . Derek clarified that "i dont necessarily see GNUe writing this stuff from scratch but rather picking 'good partners' just like SAP/Peoplesoft/Baan etc do ;)" He admitted that he hadn't looked at Zope for a while, "so maybe its grown a lot" . Jason said "zope supports practically every db now" .

Derek said he wanted GNUe to be able to have "a 'home' page feature" with "executive 'summaries" . However, "it would be 'highly' customizable so you could do 'purdy' charts and graphs etc in addition to just plain numbers" .

(ed. [Peter Sullivan] I've seen this sort of functionality referred to as 'Balanced Scorecard'.)

Two days later (http://www.gnuenterprise.org/irc-logs/gnue-public.log.17Dec2001) , James confessed that "zope rocks my socks - it's come a long way since I lasted looked at it" . However, it wasn't a potential replacement for GNUe Application Server, just "a pretty powerfull web site builder" Bill Gribble (grib) flame-baited that "zope is cool despite the fact of its python-ness" , but Derek pointed out that "python-ness == good thing (tm)" on this channel.

Later, Stuart said "i've been looking at the zope cmf stuff - fairly nice stuff for 0 $$" . James said "i haven't played with the cmf stuff yet but the core zope seems realy nice" , although he didn't think much of the documentation. Stuart said "zope book helps - and zope developers guide is kept up to date now."

Bill said "I just wish it played a little nicer with php." . Stuart said "there's almost always a way to do it... you just have to know how ;)" Derek said there probably wasn't enough demand at the moment for a conversion tool - "you will see it the first time someone needs to convert a large site and does so in an automated fashion and then relesaes the code for others" .

Derek said he had "a theory that php can create apps to a certain celiing but then became unmaintainable" , although "that ceiling is fairly hihg (read not many people will hit it)" Stuart noted "i'm doing my new site in zope, because it's going to get very large, very quick and I need to admin that" . Derek said the benefit of "zope's approach is regardless of size it tries to do things that ENFORCE maintainability" . He added "i think it is like the python vs C argument in some ways" - you could write good code in C if you were disciplined, but python tended to enforce good coding habits. This was partly why GNUe developers "were preferring python more and more" .

Bill Gribble (grib) asked "any of you gnue folks used the current tools to do inventory/asset lifetime management?" . Derek Neighbors (dneighbo) said these were two different things - asset management was more to do with capital assets, as " opposed to 'on hand' type inventory used in production or for sale" . Bill said " just looking for info to file away. I'm working on a asset lifetime tracker (using some of our tools) for a client and wondering if gnue had some insight to offer" Derek said there was " some inventory info" on the website (http://gnuenterprise.org/~neilt/packages/supply-chain/package-doc/SupplyChain/inventory.html) , as was information about "the capital management (http://gnuenterprise.org/~neilt/packages/supply-chain/package-doc/SupplyChain/equipment.html) (or assest stuff)" . He added " financials are coming slowly, we havent really focused on them - still playing a lot with the tools - it looks like our 'manufacturing' stuff and 'wholesale distribution' stuff will be the first to come as there are people asking for them" .

After getting GNUe Forms working, Phil Cole (fil_c) had "Some questions: How about multiple languages? Each .gfd file is language specific. And how to cater for different lengths of text for each language?" Jason Cater (jcater) said "the next release of GNUe Forms intends to address several of these [...] we are going to try to better incorporate i18n into the next release but we are still up in arms about how to do it." At the time of writing, you did need a seperate GNUe Forms Definition (.gfd) for each language, although it might be possible to "dynamically generate" them from GNUe Application Server in the future. i18n support was an important issue for GNUe, as "we have quite a few international users who keep reminding us of where we're lacking :)" Phil said this sort of functionality could also be used for "end user personalisation (e.g. (re)moving the fields on a form" . Jason said this was "definitely worth considering" .

Phil said you could split off the triggers - " still leave the xml definition but the action occurs in a trigger file " . Jason said "we can do that now with <import-trigger>" - you could re-use most objects, including datasources, "but that certainly doesn't solve the multi-language problem" .

Phil suggested "one way could be to move all "language" to just be labels. Then the actual text for the labels be defined multiple times" . This would also cope with different lengths of text even within the same language, e.g. "'Purchase Order' and 'Pur. Ord.'" Or you could have different .gfd files for each language, "or both of the above" . Jason said "I'm not sure if that's the ideal long-term solution" . Phil asked how to "cater for different positioning of form objects due to differing language lengths." Jason said "we currently only support absolute positioning" and asked " how would you do dynamic length labels in an absolute system" ? Phil said "I dont think that's possible. It would require a separate .gfd for each language" . Jason said "the main drawback to this method is that if a form is changed (rearranged) you have to modify every language file, instead of changing just one [...] or that the translator would also have to worry about positioning as well as translation" . Phil agreed, and suggested "perhaps we could make the alternate language forms optional - treat english as a master and use it and it's position but with foriegn labels if a specific foriegn form doesn't exist."

Later, Derek Neighbors (derek) said " as for muliti language i still think we shoudl use 'entities' so you can define entity files for incluces then do substitute" . This would mean "all you have to do is change the entity tag in the form to your country code" .

See also previous discussions about i18n in Issue�#5, Section�#1� (18�Nov�2001:�Hindi(Devanagari) characters in GNUe Forms) .

Reinhard M�ller (reinhard) reported back on the problems compiling GNUe Application Server. He said the "easiest way to get around this is to configure (autogen.sh) with --disable-python-methods. Other way is to set the environment variable LDFLAGS to the directory of libpython2.1.a while configuring (autogen.shing)" . The python check macro had been " stolen from some other project IIRC" but wasn't ideal. If it could be improved, " we can contribute it to automake IMHO"

James Thompson (jamest) said that he wanted "to attempt to graft the common dbdriver system into geas" instead of the high level API it was using. He would need a "good set of docs on embedding python" . Reinhard M�ller (reinhard) volunteered to "do the geas side if you want" James asked "so if I make a common c lib interface we can graft that in to geas" ? Reinhard said "my understanding is you have to write a c wrapper around the python lib" . James said that was one way, but also "the C api can manipulate the objects directly" so you did not need a wrapper library. He added "my hope is that if I can graft this in we'll gain a few things - GConditional support, about 15 more interfaces geas can use :)" . He should be able to do start this over the next two weeks. Reinhard said " we should agree on the interface as soon as you know it's doable - before you start real implementation" .

He asked whether "the new dbdriver (shall we call it gedi?) system" was intended to just support python, or C as well. James said "most the db drivers in python i believe are written in C with a python interface " anyway. Derek Neighbors (dneighbo) said you could "do everything in C" , but this was probably only worth it if speed was a concern. He didn't see dependancies as an issue - "i see as we mature we will build stable snapshots of ALL dependencies and post on our site and bundle with our installer" . This didn't rule out the possibility of a non-python driver, " but it means really rewritting common in C" .

Reinhard asked what version of python the "common dbdriver system" would require. James said GNUe was standardising on python 2.x - "the loss of 1.5.2 support was a deliberate move on our part" . Reinhard said this meant that if he wanted to re-use the drivers on another project " because i get 15 db's supported automagically" this would create a dependancy on python. But "as soon as we have the c api we have at least the theoretical option to recode common in c and be compatible" . James agreed, but said "I don't see much need unless performance suffers" , as even Windows could suport python now. Reinhard asked where the "api of the dbdriver system" was documented. James said "DataObjects.txt - well it's called GDataObjects in the code" . Reinhard said he would read it and comment.

Phil Cole (fil_c) said "One of the major areas that causes issues in ERP vendors software seems to be reconciling invoices received against purchase receipts made" . This was because "there are partial receipts, partial invoices and differing financial periods." He explained "In our system when a purchase receipt is made a financial posting is made an accural account... then when the invoice is recieved posted into a received invoices account" . Stuart Quimby(ToyMan) said "matching to the PO shoud be straight ahead if you use PO #'s" . Phil added "... then the invoices need to be matched to the purchase receipts... and the purchase receipt account matched against the registered invoices account... .. this is where we have problems." . Stuart said this was "one of the messier aspects of things, no matter what sf you use... but good software makes it better" . Phil said "... we should be able to reconcile recieved invoices account ledger account balance by looking through the logistical postings.. .. and this hasn't been working for us" . He explained "we use a single supplier creditor account and a single recieved invoices account which shouldn't be an issue" . Stuart agreed - "you'd only have to have more if you needed to break it out" - for instance, to split "office supplies from raw materials" . Phil said "we would probably do that via statistics codes on the items purchased" or by posting to different General Ledger account codes based "on something in that purchase receipt (e.g. item code of purchased item)" .

1.	12�Dec�2001	(1 post)	Friendly and Unfriendly Packages
2.	11�Dec�2001�-�12�Dec�2001	(10 posts)	Human Resources draft proposal
3.	13�Dec�2001		Empty Queries with GNUe Application Server
4.	13�Dec�2001		Python 2.x dependancy for GNUe Forms
5.	13�Dec�2001		GNUe and the GNU Public License
6.	13�Dec�2001		GNUe Forms User Interface re-write
7.	13�Dec�2001		Storing GNUe definitions in a database
8.	13�Dec�2001		TODO list for GNUe
9.	17�Dec�2001		Content Management Systems for GNUe
10.	17�Dec�2001		Inventory and Asset Management
11.	17�Dec�2001		Support for multiple languagues
12.	19�Dec�2001		Problems compiling GNUe Application Server
13.	19�Dec�2001		Database drivers for python and C
14.	19�Dec�2001		Reconciling Purchase Invoices to Purchase Receipts

GNUe Traffic #8 For 22�Dec�2001

By Peter Sullivan