In , Patrick Baaker had asked for a list of people using GNUe in production. Derek Neighbors said I will give you this offlist as not all entities publicly are willing to admit to using free software. Kind of silly huh..

Patrick said he was concerned forms may be too limiting from what I've seen(but I would have to take a closer look before I would decide). Derek said If you let us know where forms is too limiting we might be able to help.

Patrick said I was thinking in terms of having layers of definitions in a report to split things like headers/footers, the data itself, and a pull-quote style summary of some portion of the data. Derek said We plan to support leveling in this fashion.

Patrick had not seen any mention of FOP, although since it is part of Apache, its in Java. Derek said that GNUe Reports would support FO (formatted objects). As GNUe was pluggable, you could even use FOP from apache if you so like to go from our FO to PDF. I imagine if an FO->ps,pdf,etc isnt ready for python by the time we get there, that we will either use a java one until a python one becomes ready or consider converting a java one to python. :)

Harald Meyer had reported a problem to the mysqldb guys and it seems that they are arguing whether this is a mysqldb fault or a gnue fault, because we call fetchmany without doing a check as to whether the rowsadded were less than the maxrows. However, they had provided him with a patch. Derek Neighbors said Im not sure I follow. The first reply seems to say we are wrong we need to use =None (which is what we had and it gave us type errors) Then the next guy says you cant do None as it will give you type errors (which is what we experienced and why we changed it). He then goes to say the bug lies with them and submitted a patch.. He asked Have you applied this patch and verified if you problem went away? If so we know its a bug in their stuff.

Jens Müller asked What is the difference between geas and appserver? Reinhard Müller explained "geas" was an application server that was contributed to us by a company. After trying for some time to adapt it to our needs, we decided to not use it (except as a source for ideas) and write our own. We called the directory for the "new" one "appserver" to be consistent with "forms", "reports", "designer" etc. The "geas" directory is obsolete and is kept only to look up how the old application server did things.

Jens Müller supplied a patch for the documentation about business objects for GEAS.

Later, on IRC, Reinhard Müller (reinhard) noted IMHO it's *** urgent that the old obsolete docs are removed from our web page. Jason Cater (jcater) had no issues with that - or at least write a sed script to add a header to each "THIS IS OBSOLETE DOCUMENTATION" or something. Later, Reinhard told Jens (ICJ) I'm highly sorry to tell you that this doc is outdated and obsolete - because it was aimed at GEAS v1 - however we appreciate your effort anyway - our docs suck real hard :(. Jens suggested oops ... Could you put that on the first page? and could you move it to the /docbook/old directory?.

Later, Jens suggested Can you checkin anyway? I believe these documents will serve as a guideline for the creation of the new version of the Application Server.

It was asked if there were any reference sites for GNU Enterprise. Reinhard Müller (reinhard) said that dneighbo, jcater and jamest use GNUe Forms, Reports and Designer in production for projects they are involved in. It was noted that GNUe had been considered for a project to replace a Microsoft Access database, but the designers had eventually gone with phpgroupware instead, as web-based access was a priority. Derek Neighbors (dneighbo), remembering noted that gnue right now is PRIME for replacing access applications - i.e. i think that would be the #1 use as it sits today.

He said the 'need web' is interesting - although thin client might be a requirement, he didn't think that typical web browsers such as Mozilla or Internet Explorer were particularly "thin," and if you are making people use lynx for a production application i pity your users :). He admitted the correct answer is mozilla,i.e. might be thick thin clients - BUT in our case they are already on the machine.

Derek admitted that they had not pushed the web interface for GNUe, saying there is phpclient in cvs now (iirc) - also a webware one (though it might not be in cvs). However, the core GNUe developers were not personally that interested in web applications - we fully want gnue to support them but were leaving the coding effort in this area to others. They personally tended to use other thin-client solutions such as LTSP (Linux Terminal Server Project). Gontran Zepeda (gontran) quoted somone from another channel who had said heterogenous os environs demand a web-based solution. Derek disagreed strongly - GNUe clients could run on any O/S that there is a browser for.

Concern was expressed about having to install a GNUe Forms client on a large number of distributed desktops. Gontran suggested create a nice installer?. Derek said the only time i see web app having a real advantage is if you have LOTS of clients you are not in any control of i.e. CLASSIC web applications. But in practice, most companies would not want standard ERP functions such as inventory, financials etc shared by the masses of the internet - most of those applications are behind firewalls.

Derek said the negatives to web-based applications were that a. the widgets are not conduvice to high volume entry/validation - b. statelessness sucks :). However, he recognised that its EXTREMELY important for gnue to have a webclient :) for use where it was appropriate. James Thompson (jamest) said that GNUe's web clients would not use java - they would be server side for now with the browser only on the client side. Derek pointed out btw: an applet is not a web application - as you have to download .java files to your computer - so your argument of 'distribution' to lots of users over the world is then lost - as every time you upgrade they will have to redownload applet etc.... (iirc). However, it was felt that a java download was fairly painless for the end-user.

Derek noted with geas i think we can have something similar to applets - you download (via good installer) the client - and have it point back to a GEAS server - and you are off to the races.

Marcos Dione (StyXman) reported a bug running GNUe Designer - NameError: global name '_' is not defined. He wondered if this was because it can't find the messages for gettext. He was installing CVS in his own directory, not as root. Jason Cater (jcater) wasn't having the same problem, but I bet he has a locale setting whereas I don't - so mine is falling back to the dummy _. He asked did you run ./setup-cvs.py - or the individual ./setup.py scripts in each tool?. Marcos said he had run setup-cvs.py, but it doesn't install designer.. Jason said it should. Looking at the source, he spotted a bug in setup-cvs.py, which he fixed and then asked Anyone running CVS copy of tools: Please update your CVS checkout, do a rm -f ~/gnue/translations, and then rerun setup-cvs.py. He said StyXman: btw, this may not solve your problem - but then again it may :). Marcos said that Designer was generating a warning 'Unable to load locale information falling back to dummy _()' - but it loaded... Jason explained I didn't actually change anything in there - but the way it was - each time you ran ./setup-cvs.py, it would create another level of "translations" i.e., after 4 runs you'd have translations/translations/translations/translations/.

Marcos asked what's _() used for?. Arturas Kriukovas (Arturas) explained when you have string in English it shows, that this string has translations. Marcos asked from Desugner.py, I realize that it can handle several instances. I think an instance is like the representation and handler of a form? Jason explained well, technically, it's an instance of a designer object - with FormsInstances being the only currently implemented type - but we'll also have report instances, biz rules instances, etc.

Further to , Derek Neighbors (dneighbo) said nickr: i want to get you moving on docustore if you are still interested. Nick Rusnov (nickr) said he had layed out a good schema for it on a recent trip. Derek said i am seeing a need for us internally to have a way to manage our documentation - it is out of hand right now - so why not eat our own doggie food. He said the project needed a nice web interface (or forms interface) to our documentation - so it can be stored 'physically' all over the server (if so desired) - but have a unified way to get at it. He was really thinking of trying to make it like a library in a sense - i.e. categorized, searchable etc etc - and then i started thinking hey wait some of this stuff is the same thing a lawyer or doctor or xxx might need to get at their 'documents' - maybe i should be thinking about document management here. This was without even getting into versioning and such.

Nick said his current plan was to allow youto store a notional docgument as a URL/md5 sum or thhe actual data. He would do a dia of the schema I havwe in mind. Derek said even a database that does meta data and just stores a url would be a huge win :). Nick said the metadatabase and actual storage thing are pretty independent - and so is the libarary which is a layer on top of metadatabase. I'll start laying out the metadatabase componant when I get the chance. Its actually kind of neat - you recall before that I had a fixed sort of versiniong relationship? I changed that so there are 'relationship objects' which define various classes of relationships between documents - eg version-of, derivative-of, etc - each would be well defined so you could track the genaelogy of a particular document these rel/ationships could also provide heuristics for inheriting metadata.

Reinhard Müller (reinhard) asked for a quick summary of if i have a database and i want to read data out of it what do i have to do? (using common of course). James Thompson (jamest) said first you have to initialize a datasource - this will require setting a few vars in a datasource instance then calling it's initialize function IIRC. You'll also need to create a connection manager - and tell the datasource to use it (this gives you connection pooling). Reinhard asked where can i see the instance vars of datasource?. James thought probably the best place to look is in GDataSource.py - look at the bottom of the file in the xmlElements - the attributes are the things that can be set from an xml file.

He said if this is for geas2 and if we use xml files to define the datasources then you don't really need to worry much about this - as the xml parser does the right thing. Reinhard said geas will define the datasources dynamically i think - _if_ we use xml files - i don't think the parsing of the file will be at the same time as the creation of the datasource object in memory.He would expect it to work like this: client requests an object from appserver - appserver checks if class name is valid (needs xml definition for that) - if valid then appserver translates classname into table name - then appserver creates datasource object and fetches the data. This would need some translation between the xml definitions (= object definitions) and the database access (= table definitions). He explained the ideas is that appserver shows an object oriented interface to the client - most important translation here is namespace - i.e. we will have "modules" with own namespace - to avoid naming conflicts between parts of the application created by different people. In the actual database, all tables of a module will be prefixed by the module name in the db table.

James could see where you are going - you're not wanting to tie up memory with unused datasources. Reinhard agreed, saying i think a final gnue install could have some 100 tables, and sometimes there would need to be multiple datasources pointing at the same table, for example 2 users access the same table at the same time.

Reinhard said actually another reason is that i want appserver to be very modular - i.e. to separate the object repository (where the objects are defined) from the database access part. Jan Ischebeck (sledge_) asked how to link two tables (master/detail) at the appserver level. Reinhard said that we have objectlists - objects - and every object has fields - a field can be a text or a number - or another objectlist. Jan asked if a field could also be a tree? (in the more general sense of the word). Reinhard said it could be even more a web - you can have customer.orders -> returns a list of all orders of this customer and at the same time have order.customer -> returns a single object, the customer of _this_ order.

James said i need to study geas more but most of what you require is _almost_ in common - objects have custom namespaces, executable code can be attached to events etc, - however most if it is based upon idea that the parser builds the initial structure of the app - so we'll have to make some adjustments in common to do it differently. He had started working on making common more general now. He explained the parser builds an inverted tree of app objects - then the GClientApp system callings a phasedInitialization system that lets each object set itself up - the datasystem makes just such an assumption - as there is no clean API to set this up outside the parse. Jason Cater (jcater) pointed out that Objects can be created/added to a parser tree without GParser - just look at designer/Incubator. James agreed, but is it clean?.

Reinhard asked what was next after getting the datasource. James said you use it to create resultSets - which contain recordSets - which contains your data. He said you should be able to call createResultSet - if you pass it a condition tree from GConditions then that'll alter the query to match what you require, and gave some pointers to examples of how it was used in Forms and Reports.

Charles Rouzer (Mr_You) asked how is GEAS coming? Daniel Baumann (chillywilly) said he had not finished my draft architecture document yet. However, there's some inital code - reinhard added some to fit his API. He added I htink jan added support for GNURPC to geas - but I think that api will change - or at least someone will have to take into consideration what I am doing at some point. He suggested any interested parties should check out his document at /docbook/Proposals/geasarch/outline.txt - mainly working on defining the Python ODMG binding which should go into common. Jan Ischebeck (siesel) was working on the link between GNU-RPC (GNUe Common) and the Application Server, and arturas is doing i18n. Christian Selig (sledge_) felt that i18n should wait before major production releases, because (at least from my experience) having all translations catch up with the primary language is a nasty issue.

Two days later, Jan said I've read odmg.txt, but its some time ago. outline.txt is informative, except of the overview at the beginning, it is mostly about odmg and how to describe objects, or how to map ODL into python objects. I think two other things are also very important at the moment: a) object-relational mapping (you said it) - b) more concret definition of the way to access objects. Daniel said well the client API is defined in ODMG, imho - it just needs to be worked out.

Daniel explained that the Application server would need metaobjects - objects about objects - so you can change the schema on the fly. Eventually, the meta object api could be used by designer to create new business objects - then from those odl files can be generated and python code stubs can be generated. Jan was impressed - GEAS V2 will be great.

Three days later, Jan said he had talked with chilly about odmg.txt. ..and found a book on my bookshelf about object databases.. Reinhard Müller (reinhard) said he was keen on ODMG as well, however i feel a strong urge to only implement what's needed. Jan asked whether this was just to get working code sooner, or for performance issues. Reinhard said his motto was "something is perfect not when there's nothing left to add, but when there's nothing left to remove" - which sums up all issues from performance over maintainability to implementation speed :).

Jan said I would like to implement views. That would allow to handle attribut and method access issues on an object access level instead of complicated attribut and method acces rules. He explained Its like views in postgres. You define an object which is an wrapper for the real object, but which only allows read access for example. This would mean everybody gets access permission to that new object (the view) and just root has access privilige for the other one.

Jan Ischebeck (siesel) asked is information available about the status of every driver of the db abstraction layer? like x has feature x,y (i.e. introspection) and # y is rather instable..... Jason Cater (jcater) said um - we have common/README.datases - it will need to be updated before our release. Later, Jan noted that, although its quite complete, i still think their are some informations missing for example, if the database adapter supports introspection - the ability to query the database to discover what tables and fields it had. Jason said we will add that before the next release - which, for the record, we are targeting at next weekend. From memory, though, introspection is well tested for all the postgresql and oracle drivers and has been used (but not sure to what extent) for mysql, db2, firebird/interbase. He added I know it exists for (but not well tested with) SAP-DB.

Tihomir Purgar (the_grunf) said i'm using mandrake 8.2, and there's no way i can install wxGTK...it says i need libpng.so.2. He had libpng.so.3 and had tried doing a link to "alias" it, but seems like configure is smarter than i. He confirmed that Mandrake GNU/Linux used rpm (RedHat Package Management) - he had downloaded all the dependencies and i'm stuck in this prob. James Thompson (jamest) said i don't see where in wxPtyhon it references libpng :( - my source is old though. One thing you could try in setup.py change the CORE_ONLY = 1 - i have to do this on solaris to get wxpython to build.

Tihomir posted his rpm dependancies error messages. James asked doesn't rpm dependency checking only look for installed RPM packages? If any of the dependancies were present, but not installed via rpm, it might be worth telling rpm to ignore dependencies during install - i think I used to have to do this when mixing source and rpm installs.

Later, Derek Neighbors (dneighbo) said that he personally recommended either compile everything or compile nothing imho on rpm-based systems. He had installed both ways and gotten it to work - source install is suprisingly easy - though i would almost bet that all the dependencies are actually on your mandrake disks in rpm format if you have even a relatively new mandrake distribution.

Earlier, Tihomir followed James' advice to switch off dependancy checking in the rpm installation, and then got some error messages from GNUe's own setup.py file - No valid UI drivers are installed on this machine:. James asked do you have a DISPLAY var set? - as the checking tries to open an connection to your xserver - this burns me all the time on remote installs :). Tihomir confirmed yup....i'm running X now....

James pointed to the gnue-diag.sh in common/scripts/. This was created to scan installs and find issues - but it's fairly old - not sure if it still works properly. Tihomir tried it, and reported grunf....it says i have wxPython installed !!!!!, wondering so why is this gnue-diag saying i have wxPython installed and setup.py doesn't...? James said the difference might be the gnue-diag looks to see if the file exists via a shell command - the setup.py actually trys to import it. He suggested trying to import the wxPython file manually - this way you can see the error wx is hitting. Tihomir cut & pasted his python error message.

Derek said i think this is probably a python problem - you have python 1.5.2 still on this machine? If so when you installed wxPython it probably installed for python 1.5.2 - and now the operation you are performing is probably looking for it in python 2.x - and so rightfully its saying it does not exist. Tihomir said he thought he had dowloaded and installed wxPython for Python 2.1. Derek got the_grunf to check his python version, and concluded ah yes you definitely need wxPython2.2. Tihomir downloaded and installed it, but still no work. Derek suggested running setup-cvs.py from the root gnue directory, instead of the setup.py. This did not give any errors.

When starting the Forms client with the intro.gfd sample form, there was a problem with the mxDateTime dependency - lets fix that for you :) - jamest: should i file bug that setup-cvs.py didnt catch that?. James said setup-cvs.py doesn't seem to do dependency checking - at least not for things like wxWindows or mxDateTime - i understand the wxWindows not being there but I hit jcater up about mxDateTime when he shows up. Jason Cater (jcater) said he hadn't considered it before. James suggested checking only if it's something all gnue apps depend upon - like the python check - as reports doesn't need wx to live - but the db driver system dies w/o mxdatetime. I almost think this should be part of the installer - and the developer setup shouldn't need it. Course that implies we need to release - so that people aren't forced to cvs :). Derek said i think the developer setup should have it all - as it INSTALLS all packages. He added i do agree about release so that we dont have people using cvs install.

Tihomir reported that he was now getting an error message Unable to load locale information falling back to default English language translations. James said that's fine - basically you haven't set an localization - or our system doesn't know your localization - that is very much a work in progress. However, Forms was not loading. Jason suggested running it with --debug-level 10. Tihomir pasted the debug messages, and Derek concluded ok - so we still have wx problem. He felt we really need to retrace all your steps - and systematically uninstall all you have done relating to wx* - so we have clean slate. As best i can tell it looks like its installed just not quite correctly - i.e. its out there under python2.2. He suggested can i get you to uninstall the rpm for wxPython which had come with the Mandrake distribution and try this one instead directly from SourceForge? This proved to solve the problem, and the sample form finally loaded.

Derek concluded when people say rpm is as good as apt - my response isnt rpm is a bad packaging system - its that Debian is MUCH better about QUALITY of its packaging :).

Jan Ischebeck (siesel) asked does anybody knows if database fields with spaces or special characters are supported?. Peter Sullivan (psu) remembered , saying GEAS will use double underscores in places. Daniel Baumann (chillywilly) said I don't think GEAS is totally defined...I see nowhere where a object-relational mapping is specified (yet) ;) Jan said it would be great to have a definition soon.. I would like to test how common/dbdrivers and appserver can be connected.

The next day, Jan said he had made some changes to setup-cvs.py and asked for comments. he said there is still one problem with the gtestcvs command now. You have to be into common/src/commdrivers/_test to test the rpc server. So if it doesn't work, you know why. He also noted dbdriver/popy introspection support is broken. I have a "bit" dirty fix, and am not shure if i should commit it, as my patch is dirty, because I patch it in the _pqsql directory and not in the popy code itself.. James Thompson (jamest_) said what we've typically done is copy the non-std function from _pqsql into the driver and patch there. Jan said this could be done, I've just been too lasy.. He confirmed server.py is fixed. now the whole test case should work. GTest.py outputs a menu and you can choose which testcase you like to run (f.e. donut rpc test client, test server, geasRpcClient, or the appserver/test.

Jan also asked about quoting of table and row identifiers? To my knowledge this is not done at the moment. James said we probably should. Jan said he like to include spaces in table and field names for improved readability. James wondered if all db's support that? - mysql<cough>. Jan said he would expect that every db use a different quoteing style. so there should be a function "quote_identifier" in GDataobjects which can be overwritten by the drivers code. James suggested putting it in _dbsig.

Later, Reinhard Müller (reinhard) reported appserver basic data access works (read only). He had had to make some changes to Jan's code - the interface of geasSession has changed - should be no biggie to fix it again. If i can help you please let me know - however RPC doesn't work here (missing packages) so it'd be cool if you could fix it :).

On coding standards, he asked for confirmation that most of our objects have the same name as the module? - this is because we have a source file per class, right? Jason Cater (jcater) said not necessarily - but there was enough code for Datasources to justify their own module. We don't have strict rules governing what's in a module - other than neither of us like 1000+ line files. He explained a module is either - 1) a directory with an __init__.py file or 2) a .py file. Reinhard noted that and 1) consists of a lot of 2)'s ?. He concluded i think after a week of python programming i start to understand the basic concepts of the language ;).

Nicholas Lee (esands) asked Is there a quick 'howto' for building all the binaries within an alt-root. ie /home/foo/src/gnue/ rather than /usr/local/ from cvs. Daniel Baumann (chillywilly) suggested check out cvs and run setup-cvs.py - it will install things in /home/username/ for you. Nicholas said Ok. Now just a matter of figuring out the db setup and trying some of the samples. Thanks.. Daniel noted btw, I think there's going to be a new release soon ;). Nicholas felt Isn't every cvs commit a new release? ;). Daniel said in the sense that there should be better and more upt to date documentation ;) - and it will be an officially supported version ;) - not that you can't get support here though :). Nicholas thought that documentation was certainly worthy of a release. I was trying to figure if some of the stuff at http://www.gnuenterprise.org/docs/ was really "Updated: 14 Jul 00". Daniel noted the Forms API will be in the new technical reference ;) - instead of having to grok it form examples, etc.. Nicholas suggested a nice article/howto for one of the linux site going into the step-by-step mechanics of setting up a first stage gnue installation. (ie. for doing form development work.). Daniel said that a brief outline would be:

Nicholas said that was a good start - now add 1000 words. ;). He asked Is there a man describing the *.conf files?. Daniel said he wasn't aware of anything other than the comments in the *.conf files themselves. Nicholas suggested Another thing you guys should setup is a CPAN like place where outside developers can contrib applications so others can see what can be done. Daniel said I am not too familiar with CPAN but we plan to have an arhcive of packages built with the tools - and our core packages. Nicholas felt that CPAN stregth is i. its search/archive mechanism, ii. its easy of install using the Makefile.PL system.

Three days later, Peter Sullivan (psu) asked if there was any useful distinction between User Documentation and Developer Documentation, as the current web site had two seperate hyperlinks that pointed to the same place. He asked what are our working definitions of "user" and "developer"? Perry Lorier (Isomer) suggested user someone that doesn't know python - developer someone that wishes they didn't know python. Daniel Baumann (chillywilly) said all internal and hacking guides would be in the Developers' section, but there isn't much right now of that.

Derek Neighbors (dneighbo) said notice the developers one says coming someday :) - the idea was 'developer' documentation belonged in one place and user documentation in another - at this point i would say we have very little 'user' documentation - and even then its not 100% crystal clear - as we have 'development' tools - so should the docs on how to use the development tools be user or developer docs :)? He would like to see documentation by product - so say there is a FORMS documentation page - and a DESIGNER documentation page etc - and then in each one of those pages there is developer and end user sections - same for the packages - but then there is global doc page - that shows all developer or end user.

He felt the biggest problem was we wont standardize on doing docs a single way. He said the original idea was to have compendiums built - i.e. books built off the smaller documents - so one could say i want every document from gnue - and get a fat old pdf file. Peter wasn't sure this was necessary. Derek said it gets asked for ALL the time - most people dont like going all over the world trying to get information (our current state is REALLY bad) and downloading lots of little tidbits of information - especially those that like to kill trees and read later. He felt if you do indexing properly and chapters correctly - when it rolls up - its still relatively easy to find things. In a typical IRC topic drift, the conversation then mutated to the similarities between accountancy and Marxism.

Compiere was referred to again as a possible altenative to GNUe. Daniel Baumann (chillywilly) summed up previous discussions from and , saying I have heard some peope talking crap about it in here before ;) - only because it has nasty dependencies or something. Andrew Mitchell (ajmitch) said it needed non-free software, notably Oracle. Daniel said we support Oracle - but we also support a LOT more ;). Robert Dean (rdean) confirmed that Compiere's wesbite mentioned they're working on pgsql support, later adding that the oracle specificity is derived from using Oracle extensions to SQL. Andrew noted compiere also requires jdk 1.4 from sun :), which was not free software either. On licensing, Andrew noted that the compiere public license is MPL with only a couple of modifications, which would mean Compiere, Inc can roll your changes into a proprietary product.

Derek Neighbors (dneighbo) said im going to be the big devils advocate here - i see lots of commits, but we still need to release :). James Thompson (jamest) said the recent commits are trying to fix some issues prior to release and work final bugs out - as we're jumping to 0.3.0. Reinhard Müller (reinhard) wondered if it was really necessary to do even/odd before 1.0?, with odd numbers for "stable" releases. James said i don't want even/odd at all anymore - but I'm in the minority :). He was 1/2 tempted to say this is a 0.5.0 release in alot of ways.

James said if things release today we have the following issues:

Jason Cater (jcater) added lots of untested i18n changes. James didn't think would be an issue - the i18n is cake to disable for a release - just modify GBaseApp to always call the dummy _(). Jason said this was what he was worried about - don't know what exceptions, if thens, etc, have a _() that we haven't had code run against :). Derek picked up on James' statement that gnue.conf isnt needed? James said testing today shows it is - but it should not be as the system now has all defaults in a .py file - that can be overridden by gnue.conf. When time permits I'll make the new config system write config files too - it's real close to that today - then our installer can create them on the fly if needed. Derek thought this sounds dangerous to me as he did not think defaults belong in a py file.

Derek proposed from now on if we go into a segment where we are getting ready for release we branch the code - so things like rewriting the conf system and doing i18n and such are in the branch and we dont have to 'wait' to do releases - as this is always what kills us - is 'features' not fixes keep getting added in the last push for a release - this is why we need roadmap more clearly defined - so we can say xyz will be in next release - anything not xyz goes in a branch. Jason said the distinction between "feature" and "fix" was often murky, citing the conf system changes as an example. Derek agreed - i realize a lot is dictated by 'need' - but i think if we kept a version branch to help us stay focused it would help - but wouldnt prevent people from adding stuff that was 100% necessity. He noted btw: this is the same issue debian woody is having so its not a direct criticism per say - there may not be a good answer.

The next day, James asked where are we at wrt to release? Jason said well, the biggies iirc were gconfig support and derek's trigger troubles - which are probably a lack of understanding of the new way - which implies better documentation. James said considering I don't recall the right way I'll cut him some slack :) He couldn't recall if the documentation had been updated for this yet.

Derek said i really think we need prequery support added back in before release if its not major, as previously discussed in . Jason said that's not just a bug fix. Derek said tecnically it is - as it used to work - so it being broken is a bug :) Jason pointed out that it had been broken for a year, and I can almost promise we'll introduce bugs by doing it :) James said that prequery has to work or dropdowns wouldn't work today. Jason said prequery DOES work - but it's not doing like it did last year.

Later, Daniel Baumann (chillywilly) asked hey when is the new forms, designer, etc. release? ;) James said be on the lookout for airborne pork as he was stomping bugs now.

The next day, James noted dneighbo: your autofillBySequence works again - it was technically never broken - however I broke the preInsert trigger than ran it :). Derek said he would test this later. He asked how did things go last night 're getting ready for release?'. James said ok i guess - i started to work on prequery - which is easy to add but messes up the UI on master/detil.

Alexander Brill (kiOwA) asked about available packages/templates for GNUe. Peter Sullivan (psu) said the website is out of date - we have a redesign in the works. He explained at the moment, the tools are pretty much all we have (Forms, Reports, etc) - if by "package" you mean Financials, HR, Payroll, SCM etc - then all of those are stalled at the moment - some we have proposals for, some we don;t. The sticking point has been that although we *could* write packages using two-tier - ie forms talking direct to database - we don;t really want to - we really want to use n-tier - ie forms talks to appserver talks to database. The project had ju7st started an appserver re-write - once that is bearing fruit - we can start on the packages for real. In the meantime, 2 tier (forms to database) is *very* usable for people who want to write their own apps, noting several of the guys here use Forms in production.

Alexander said I program in python, so your project seemed like my best bet ;). Peter confimed we live & breathe python here - even I've become infected. He said The other benefit of hopping onto GNUe now is that if you write an app in 2-tier (i.e. forms talks to d/b) - once the appserver is ready to rumble - moving to 3-tier (forms talks to appserver talks to d/b) should be an easy conversion - basically take all your triggers and business logic out of forms - and put it into appserver. This might even be possible to automate.

He concluded basically, if you need an off the shelf ERP package to go live tomorrow - then no, we're not that - If you need a convenient toolkit to write database apps of simple to mid complexity - we're here already. Alexander said I was looking for something that I could customize the hell out of... And shrink-wrapped isn't my kind of style. Peter said We like customisation - as GNUe packages will be GPL, nothing to stop you re-writing source. But even beyond that, we already have concept of "templates" which you can apply to packages to apply country-specific or site-specific functionality.

Alexander Brill (kiOwA) said he Was thinking about creating a customers-base with everything that evolves around. We were already thinking about starting that work using webware (python-wrapper for web). Peter Sullivan (psu) said we have a PHP-based web client in CVS. Dmitry Sorokin (ra3vat) said there was also forms driver for webware but this was not in CVS. Rather than use web-based applications, Peter said that the main Forms client in python works on both GNU/Linux and Windows.

Later, Jan Ischebeck (siesel) confirmed that PHP is working great in combination with postgresql.. As of time of writing, its standalone. just copy the two php files into your web directory and it should work - but i've planned to use python common over RPC. so I begann to add an modular database adapter system, and worked a bit on the RPC stuff... RPC is now running, but it makes not much sense to use the actual common/dbadapters per RPC in the phpclient. I.e. phpclient will just work with postgres for a while.

Calum Morrell (drochaid) asked about building support for biometrics into GNUe. Peter Sullivan said I guess I would perceive it as an add-on - main issue is that most clients today are PCs and have no biometric support - unless you buy the £50 fingerprint detector. I know sklein is the main player on security issues - but he rarely shows up in IRC - he obviously has a life ;-). He felt biometrics are a possible solution to a real problem - in that some orgs have a culture of password sharing - which can't be allowed if you are going to make the best use of ERP - becuase you have to be able to depend on login being who they say they are. Calum said that many people used easily guessable passwords. Peter felt things like LDAP & single log-in can make things worse - as people don;t think thru - that giving your secretary your p/w to print off that word file also gives her access to the requistion screen in Purchasr Order Processing - for that luxury cruise s/he always wanted. Calum said he firmly believe a person should be identified by who they are, and not what they know.

Charles Rouzer (Mr_You) asked ya'll seen the HR-XML stuff? He was not sure about the licensing. Gontran Zepeda (gontran) cut & pasted some of the copyright notice, which suggested that if gnue documents how to use their markup, the copyright for that documentation has to be assigned to hr-xml.org?.

Later, Derek Neighbors (derek) said as long as we have permission 'technically' we could use a definition - as its not code - but i dont know if its a good thing to do per say. He noted that Richard Stallman or FSF general counsel Eben Moglen woudl be the authority to ask - but at this point unless someone is pursuing an HR package and jumping on it - would rather not go there. Charles said it looks pretty GPL compatible to me but I just glanced. Derek noted that GPL compatiablity is pretty tough - free software is pretty easy to obtain, just follow the rules to freedom - GPL compatiable is more tough as it requires something to be more copyleft and any thing that 'demands' acknowledgement or has odd verbiage is usually tossed - i.e. many a licenses deemed non compatiable because the authors wanted some attribution or logo dispersed with code - BSD/Zope are two that come to mind.

Charles said that if these issues could be resolved, it seems to me.. that hr-xml could be our HR package. Derek said the last time he had looked, it had ONLY had hiring portion spec'ed i.e. they had format for resumes. Charles said they have a bunch now [...] version numbers and all. He was just bringing it up as I imagine some biz will want it in the future - or will require it per interfacing with Manpower, etc, etc if XML becomes what everyone wants it to be.

Continuing , James Thompson (jamest) said he had fixed the gettext issue i believe. Bajusz Tamás (btami) said that working i18n support was essential for me. Arturas Kriukovas (Arturas) said James had done most of the work. James said i just move code around to make it fit a bit better. Arturas felt that i18n support should be ready in about a week. Bajusz said he had already tried it with some hu strings - and it works !. Derek Neighbors (derek) cautioned dont be decieved - working is 'relative'. Bajusz said he was not having any problems - i'v used "Szerkeszt" in place of "Edit" in wx menu and it worked using cp1250 text encoding.

Marcos Dione (StyXman) said he had been poking into designer' code. 'vrything looks good, except for Incubator. I can't find where elements is defined. Jason Cater (jcater) said those are pulled directly from forms/src/GFParser.py iirc. Marcos asked whether all the available widgets are *hardcoded* in that file? I thought you loaded from some xml file... James Thompson (jamest) said That file is the xml to internal widget mapping so is hard coded - but that file is only the parser mapping.

Marcos asked ok, whar does that big structure mean? I see that Attributes list the valid attributes, and some mappings, but what do the rest of keys mean? James thought that was documented somewhere but couldn't find it. He explained:

Marcos asked where are the available widgets defined? I see that those are just for loading already built forms.... James said that all publicly available (via the gfd) widgets are defined in there and they are implemented in forms/src.

After some discussion about the Incubator module, James explained Incubator does something that will eventually be cleaned up but it works for now - we have no clean API for designer to work with a form yet. Jason was not sure that was fair - I think designer plays nicely with forms objects - the big API deficiency is in drawing the objects - i.e., the wx driver needs a better designer-compat api. He did not foresee Incubator changing too terribly much (as it works w/forms, reports, ....) James said he was speaking of the hacks to draw things.

Jason pointed out that the beauty of designer is that if jamest adds a l33t new widget to the Forms client, then designer can create/modify that widget without any programming in designer. It needed better documentation, however.

Further to , Gontran Zepeda (gontran) asked is nstti dusty? would you mind if i mucked about adding doc strings (for happydoc:) and cleaning up? Jason Cater (jcater) felt dusty is the wrong word... perhaps "is nstti still swimming in embryonic juices?". Gontran said he had dloaded from viewcvs the tarball and have been cleaning up -- in order to understand and document. From there i'd like to , you know, fix it. :). James Thompson (jamest) said that would be wonderfull. Gontran confirmed he was using the version of nstti in GNUe's own CVS. James explained the author let me put in our cvs as he doesn't have time to work on - i started looking at what it would take to make an nstti driver for forms - nstti is going to need work before it'll work properly. Gontran said that's what i figured but /me ADORES curses - um, as a user.:). He just wanted to make sure i wasn't duplicating work. James said we'd love the help. Gontran said i'll send you patches as soon as things starts getting fixed. :).

The next day, Gontran announced his nstti tests are starting to work :) and posted a screenshot on the web. Later, he said I'm working out some probs with the test script -- it mostly works now ... still more to test and fix in the base classes by excercising there. Once that's cleaned up -- next couple days (hopefully) I'll have a look at tying in the standard? UI hooks.. James said why don't we get you an account setup on ash - so you can check stuff into the cvs? Gontran felt he was not worthy :).

Jens Müller suggested security behavior should be defined in the object descriptions, and be examined at run time using security rights defined in special objects. This would allow groups of rights to be defined, and users assigned to those groups.

Peter Sullivan (psu) said that GNUe was that bizarre thing, f ree s/w project with a biz model that actually works - as a typical ERP project will be, like, half a million for licenses, two million for consultancy - well, I'm perfectly happy to forgo the 1/2 million and just collect the rest, thanks - since I'm not having to pay VAR fees for the s/ w anyway. Also, access to the source code was also important, as ERP projects often required customisation.

Nicholas Lee (esands) asked if GNUe saw itself as an alternative to full ERP systems like SAP? Peter said he did not see why GNUe shouldn't be going head to head with the JBOPS (JD Edwards, Baan, Oracle, PeopleSoft, SAP) & winning wherever people care about freedom and/or free beer. Nicholas said that In a sense every ERP has to be customised somewhat. Since no business process is exactly the same across entities.

Nicholas Lee (esands) asked When using the designer (wizard) to create a form I assume you have to first setup the database/table. Peter Sullivan (psu) confirmed this. Andrew Mitchell (ajmitch) said i'd like to have a designer for business objects that talks to the appserver which can create the db schema. Peter said The inetntion is for Designer to become our all purpose designer - as you might guess from the name ;-). Perry Lorier (Isomer) wanted a Singing dancing designer!. Peter said it should also be able to design reports, naviation and, yes, business objects - at the end of the day it's a generic visual XML authoring tool - the emacs of GNUe.

Reinhard Müller (reinhard) noted that for the appserver test program you have to set up pgsql so that your unix username is known to postgres and you need no password for your username as of time of writing. Andrew Mitchell (ajmitch) suggested that it should pick it up from gnue.conf? or is it connections.conf that it should be in? Reinhard was not sure if that is a good idea. He said we actually need to decide what user the appserver will use to connect to the database. When a user logged into the Application Server, should the appserver log into the db using that user's username, or a generic login such as geas?

Andrew asked so where should the password be stored? the appserver will need to be able to access it to connect. Reinhard noted it was one of the principles of the 3-tier setup that security must be handeled by appserver not by database. This meant that the Application Server "user" on the database needed a very secret password. Andrew jokingly suggested i know! we can build in an "override" password so it can be used in the movies! :) Reinhard suggested i see only one chance - store the password in a file where only the user "gnue" has read access - and start the appserver with suid flag. Andrew said that may work - but how do we start the appserver with suid flag since it's a python app? Reinhard said it might be necessary to write a "wrapper" binary? - one that exec's appserver.py and dies immediately (so it doesn't use resources all the time). However, he wondered if the file with the password in it should be referenced from connections.conf.

Peter Sullivan (psu) queried In the dependancies download section of the website, presumably we would only ever include things that were not just freely redistributable but also free (as otherwise they would not be a GNUe dependancy) but not necess GPL?. Derek Neighbors (dneighbo) emphasised that we should not depend on anything that is not free as an ethical requirement. in the dependencies section i think we should be mirroring binaries of current dependencies of gnue so say rpm's or .exe's for wxPython/wxGTK, python, etc etc. It helps for 'tech support' to not have to point people all over to get stuff imho. I think i made stuff under my home dir for python2.1 and redhat that had most of the rpms - we really need to do it for others as well. Peter said I was just working on basis that the boilerplate for that directory could assume all s/w was free (for reasons you state) but not necess GPL. Derek agreed - i think all software we offer for download should be 'free software' - but correct, not necessarily GPL or GPL compatiable.

James Thompson (jamest_) announced cvs is using new icons....to see them you must remove the tb_* entries from your gnue.conf files.