Malek Hadj-Ali asked why aren't you guys using Zope as an application server? It has a lot of features that could be reused (ZCatalog, ZSQLCatalog, ...), it's written in python, it has a big community of developper, and so on... Stan Klein noted that, according to their web page, Zope has a standalone persietent object database and They can evidently use other databases as backends, although I didn't see reference to any of the ones GNUe is using. Jason Cater said Several of the core developers use Zope as web/portal servers at their places of work. GNUe is even switching to a Zope backend for our website. But his perception was that Zope was more targeted at serving web applications / content than the sort of Application Server that GNUe needed for GEAS. Todd Boyle said that he didn't seen Zope as incompatible with any of the higher goals of GNUE and GNUe could tap into the huge amount of work already done on Zope. As they were aware of Zope, he wondered WHY the GNUe developers rejected Zope, guessing at some possible reasons.

Jason said that GNUe was not primarily a web-based application. However, it would be possible to have a web-based application server as the backend. We've toyed with the idea of supporting JBoss and (somewhat) Zope as backends, but nothing has come of this as our resources are very limited.. He felt that Application Server is very much an over-used term that has little meaning these days, describing anything from a web portal to a business rules server to a database proxy. Zope was a type of application server, but I don't see too much overlap in goals with GEAS, which was a a business rules + data server. He felt that GNUe Common already provided pretty much what the "core" of Zope would provide. He concluded My toilet paper dispenser is an application server. So is my refrigerator. I try not to confuse the two, though. There had been some discussions with the DotGNU folks about them reusing parts of our Application Server for their .NET replacement, but once again he had some concerns that the "Application Server" phrase around is causing the same confusion in this case. He re-emphasised that several of us use Zope in our professional settings and absolutely love it; but, I love it for what it is -- a web-based content server. Zope as the leading example of python programming for some time now had directly benefited python-based projects like GNUe from any contributions they've made back to the python language and python's extensive standard library..

Todd asked how would you advise somebody already committed to Zope to achieve some basic accounting needs? Peter Sullivan said Theoretically, you could re-write the existing Forms client in Zope as they were both python applications. This would give Zope the ability to use GNUe Common to talk to multiple databases and later, to use GNUe Application Server. However, he was not sure this was sensible.

Earlier, Jorge Lehner said he was currently using Zope for a Practice Managment Tool, and listed some of the problems he had with it, concluding That is, why I'm waiting (silently) for Gnue to come up with a stronger and more generic framework for business programming. He added that he, too, liked Zope a lot for what it is. Abdul Hafiz Abdullah noted that Zope's license was GPL compatible but its too generous ala BSD, X11. He preferred the GNUe Public License, as used by GNUe, that will protect our freedom.

Harald Meyer (Harald1) asked where are the methods of business objects stored in GNUe Application Server version 2. Reinhard Müller (reinhard) said along with the class definitions - we haven't set it in stone but i strongly believe it will be in the database. Yurii Rashkovskii (Yurik) asked you mean you'll store code in db?. Reinhard confirmed this - gcd or xml will only be a means to trasport it - but at runtime all this will come from the db.

Harald asked are the set of language for methods implementation a limited one? Reinhard said that support for methods written in languagues other than python is very low on priority - and i'm still not sure if it makes sense to support compiled languages for methods. Yurii suggested this might be important for the time-critical methods at least. Reinhard said that two appservers (with load balancing) could have different operating systems or processors, which would make compiled method code impractical, and i don't think compiling method code gains much performance - as opposed to for example optimization of db access.

Harald asked if thie meant that if two business objects have some methods which are identical, these have to be stored twice? Reinhard said yes, but this won't be the case very often (imho). Yurii said that, on his project, attributes & methods are separated. methods are just reffered from the database to their location at services that run that methods - so method could be implemented in any language - the only one thing is that this method wrapper must be able to talk w/ its service He felt that storing code in db is a bad idea. Harald said he did not have anything against storing the code in the db. but what I think would be better: don't store the methods with the objects, but just referr to them.

Yurii asked whether GNUe Application Server would start method code on each request for this method execution? Reinhard said he was not sure, but i think we should aim at something like - method code can be dynamically changed while server is running and on next invocation new code is active - but appserver caches method code and if not changed then it can use (precompiled) version in cache.

Reinhard said that a lot of these issues could be reviewed once they had some working code, and could see the impact of different ways of working - we can discuss about the best way to store methods for 3 years and not write a single line of code - i know it because the gnu enterprise project worked like this for 3 years until derek came and kicked our butts :). Different people had different ideas about how things would work as of time of writing.

Harald asked can/will business objects run automatically or only if the are controlled by a user? For example, automatic re-ordering of products that fall below minium stock levels. Reinhard said that business objects do not act, they are acted upon but invoked by the user or invoked by cron doesn't make much difference. Harald said he hadn't been clear about what a business object was from Reinhard's whitepaper. He asked whether the data itself is part of the business object, or is it just the definition of the data?. Reinhard said that business object can actually mean both - he preferred the terms a business object class or a business object instance where a distinction was needed.

Derek Neighbors (dneighbo) announced we have our booth officially now for Linux World Expo in San Fransisco - .ORG Pavillion Booth #6. He noted that this will be 4th LWE we have had booth at - 2 NY and 2 SF (though no one was able to man the booth last time at NY).

John Lenton (Chipaca) reported we've been fighting with datasources, cursing that you can't make one access two table at the same time... ...only that when we were over at my place last night talking about stuff we realized that no, datasources *should* be stupid, because it's the appserver where the intelligence belongs. Reinhard Müller (reinhard) said that some basic functions will be usable in GNUe Application Server (GEAS) in about a week. Derek Neighbors (dneighbo) said i dont think geas is your answer - if the datasources dont do something you need let jamest or jcater know - as GEAS is SUPPOSED to use the common data level - which means datasources and such would be the same.

Later, Jan Ischebeck (siesel) said I think that in a 3-tier environement the client=forms should as light as possible. i.e. in 3-tier env. forms don't need views or something like that. views would live in the middleware = geasV2. However, if views could be added to the db abstraction layer in common, to make 2-tier support this too. would be great. John felt nobody should be building 2-tier apps :) Jan said gnue will give you the choice. ;). However, There will be a point where some features, f.e. views, transactions, locking... will be quite difficult to add to the db abstraction in common, and where its more praticable to move it up one layer. just because of programming issues.

John suggested in a 3-tier app, i.e. with geas, all i have to do is define the 'view' or whatever and i'll be able to access it from the forms as if it were a table? and this will work even if geas is using a db that doesn't support views? and the view will be defined in some xml format? Jan agreed - but don't expect that feature for geas v.0.1 or 0.2 John said we're willing to make them happen :) i.e. code them ourselves.

Joe Konecny asked Is the GNUe project actively being worked on? I looked at the IRC logs and it really looked like a joke. Chad Walstrom said that CVS commits were probably a better guide to the level of development activity. He added that the mailing lists were usually less "off-topic" than an IRC chat room or log file, and also recommended Kernel Cousins. Derek Neighbors agreed that IRC is 90% joke and 10% development, but still the majority of the development design work is done there. One thing you will find with GNUe is that there are a lot of 'professionals' who quite frankly started GNUe to work in an environment other than whatthey get paid to work in. (read there is great enjoyment in the community) So yes IRC might seem childish and full of mindless banter, but it is fun. :) He also noted CVS commits happen daily in volumes larger than most Free Software packages.

It was asked if Designer could be used to change the table structure in the underlying database. Jan Ischebeck (siesel) said if you want to change your database structure, you can't use designer for that task (yet :). For large applications, he said currently, we are all waiting for the application server, which sits between the forms and the database - when it is usable, we can write big applications on top of the gnu enterprise tools - but you can use current gnue as a ms access replacement very well - there are some in-house applications written by some core team people. He explained that gnue reports makes heavy use of sablotron, which is an xsl transformation processor. it processes xml->text and xml->xml - thus, you have to install PySablot (the python binding for sablotron) to make Reports work.. He confirmed that the GNUe tools were all written in python - it's a really fine language. He confirmed that XML made by Designer is stored in files, but there will be facilities to let it reside on the server as well. The validation code doesn't have to be copied into every forms definition file, as it was part of the Forms client.

Marcos Dione (StyXman) said he had added a new widget. I modify GFParser. I modify UIdriver. what's next? I mean, *how* do I say that this new GFj uses UIj as visual representation? Later, he suggested could it be the WIDGETS hash @ the end of UIdriver? says it's for designer... Jason Cater (jcater) arrived and said UIwxpython. Marcos felt it's incredible how a word, a simple word, can change you whole mood. Jason said dare I ask what you've added? Marcos said it was just an icon he had taken off the maintoolbar as we think it may be confusing to inexpert users.

John Lenton (Chipaca) asked btw, is there any reason the widgets all require x and y attribs? Jason Cater (jcater) said this was for positioning. John asked can't that be done automatically?. Jason agreed,but said we have better / more important stuff to do than layout management as of time of writing and we get the most bang for the buck w/ x,y in the meantime.

Marcos explained in detail the changes he had made to support his new widget. Jason said there was nothing obvious he had missed. Marcos said he was getting an error, which he pasted. John felt it was a parser problem, but Marcos was not so sure - if it would be a parsing problem, it should die saying so. He pasted some more information in the #flood channel.

Some days later, Marcos asked if I develop a new widget, what exactly should I do in forms/uidrivers/_base/UIdriver.py? Derek said that if its a widget that will be fully supported by GNUe long haul it would go same place as others. If it was an 'unofficial' widget as discuseed in , i think it will be handled differently.

Marcos said he was trying to understand a GFUserInterfaceBase - it has the _formToUI and _formToUIWidget hashes, along with widgetConstructorFunction. The latter seems what I need, but I'm not sure. James Thompson (jamest) explained _formToUI is the form tag to UIfoo mapping - _formToUIWidget is the mapping to the numerous widgets that can be created by a single UIfoo instance. Marcos said he was almost there. James went on to explain right now the entire ui system is created from the gfobject tree built by the parser. However, this sounds different though. He suggested i'd think you could easily add a another phased init stage in the form itself but quickly changed his mind. Marcos said he could not work out why the container for his new widget is a wxPanel... He explained _createWindow is called with a container param. the one passed to my _cW is a wxPanel. should be a sxForm, I gues... James said IIRC the wxForm contains a pannel...i think this is some kind of wx'ism but he was not sure.

Reinhard Müller (reinhard) asked is there something special about variables in python that begin with _? or is it just a matter of style to name "private" variables with _xxx? (from my understanding python doesn't have the concept of "public" and "private" members in objects). Jan Ischebeck (siesel) said if I remeber right _xxx is the a style to name "private" methods. There is an other kind of pseudo "private" methods called __xxx (without __ at the end like python buildin methods like __getattr__) - what I know for shure is that some gnue code is depending on the _xxx convention to distiguish private and public methods, like GNURPC is just exporting methods without one "_" at the beginning and GTrigger (if I remember right) uses a similar thing too. Reinhard said he thought it is a good thing anyway IMHO - i just wanted to know if it's a syntactical thing or "just style".

He also asked when are python objects destroyed? Perry Lorier (Isomer) suggested when their refcount hits 0 I presume. Jan added and the garbage collector is aactive. Reinhard suggested that we need some code to close the db connection for a geasList instance sometime - when we have the list of active geasList instances all geasList instances remain referenced as long as the session is active? Jan confirmed this. Reinhard said he was just trying to do sort(brain); Jan suggested don't use bubblesort use quicksort. ;)

Reinhard suggested that when the form is closed then the session is destroyed. Jan said for forms it is no problem, but Designer might create more open connections, and if you use designer a longer time it will create heaps of old geasList objects.. Reinhard suggested that Jan should take the glory ;) and commit the changes to CVS. He asked for clarification about Designer using multiple connections. Jan said that If you use Postgres as DBdriver there will be only one connect per programm start but this might not be the case with some of the less functional drivers.

Jan said that the biggest problem he could see with GNUe Application server was implementing GConditions - I thought of adding a "without GConditions" to the v 0.0.1 entry in the ROADMAP. Reinhard asked does appserver work with released common? or would we have to do a common prerelease at the same time? Jan said appserver needs the "dbdriver/appserver" from today. but it should work with 2-3 weeks old GNURPC. Reinhard said the last release of GNU-RPC (GNUe Common) was significantly older than that, and a new release of the two-tier tools was imminent. Reinhard said i don't think we will release appserver 0.0.1 together with the new forms release, but Jan said that depended on how soon the next Forms release turned out to be. Reinhard said that, for Application Server, i think we should release what we have as 0.0.1 - maybe add a little testing before - but then we would have to talk to jamest/jcater to do a common release at the same time. Jan said I just thought it would be good to have a already released common to use. i.e. we just would add some wrapper code to the new appserver 0.1 to be compatible with the ugly dbdriver/appserver implementation of the already 4 month released gnue-common. Reinhard was not sure if i like that idea - what about helping jamest/jcater to get current common out of the door as say 0.1.90?. Jan liked this - possibly its more clean to release a new common at the time of releasing appserver 0.1. Reinhard said this might allow a co-ordinated release of common 0.2.0, forms 0.2.0, reports 0.2.0 and appserver 0.1.0, either all at once or planned over a few days, in the same way that the Gnome project released.

Reinhard said he would do some testing for appserver - and update the docs (fwics the api has changed slightly). He added from what i hear the release of common isn't delayed due to lack of function - but rather lack of time - so if we help them in the release process we could speed it up.

Later, Daniel Baumann (chillywilly) said that for a builtin-in method in python to destroy resources (close db connection) I think you can use __del__ - that method is called before the object is garbage collected, afaik. Also, for private attributes starting with "__" is sorta private in that they get mangled like self.__attribute is mangled to self._Class__attribute - attributes like _attribute are just a convention that means hey don't use this directly....I sort of think of them as "protected" attributes.

Reinhard clarified that the first release would have no object description, but this would be added for future versions. Jan did some work on the driver to link the Application Server to Forms. Reinhard suggested some directory name changes to avoid confusion with the driver for the old, depreciated, version of GNUe Application Server (GEAS). He had tried to run the geas server and the geas client on two different machines - where i found out that i can't do this because i don't have 2 machines w/ python 2.x :(. Jan and Reinhard did a test together using https:// over the internet. Reinhard remembered that iirc geasv1 took over a year until it worked with forms this way and suggested setting up a demo server for public access. Jan said this might be a 'little' security risk.

Jan asked do you have any ideas how to send conditions to the appserver?. He said if I understand it right the actual conditions which will passed to GDataObject are some kind of object tree. Which would be a bit complicated to transfer over RPC. He suggested that, since GConditions are single statements which are connected with "AND"s and "OR"s then why not transform this conditions in a standart form (a^b^c)v(d^e^f) going this way we would just transfer a table instead of an object tree (a AND (b AND (c OR d))). He thought that, both in principle and in practice this would not be a problem, because this was how Forms worked - We take this table and transform it back into a GConditions object tree. Reinhard said that there could be peformance problems with complicated Boolean logic, but most business applications in practice tended to use fairly simple conditions. The other approach to passing conditions to the Applications Server was to pass lists. He explained my thinking was to make the method to create a new instance of a class - not be a method of geasList - but of geasSession. But now i see that it makes sense to put it into geasList when i think about how forms works. Jan said to be honest, I don't like to have it in geasList too. but geasSession isn't good either. Reinhard said it made sense because geasList is the list of instances that can be scrolled through in the form.

Jan suggested I would like to have a geasClass in between, which also holds the class definition and can create new instances - it doesn't have to be a member of geasList, because every new record in forms stores an pointer to the new created geasInstance, but I still would seperate the functions which are in geasList now into two classes. Reinhard said he wanted to keep things simple. Jan said If I create a new list, just by executing a query. then it really should be a new List and not the same list populated with new values. Reinhard did not see why not. Jan said it is ok, if you have just one client which access only one table at one time. I would prefer a geasClass which could generate Iterators, or something like that. However, they both agreed it was more a matter of personal taste/programming style.

Reinhard did a todo before 0.0.1 list:

The next day, Reinhard Müller (reinhard) reported good progress :) on the GNUe Application Server re-write - you can use appserver for remote data access without methods - it simply passes through the data requests to the database. He admitted doesn't sound sooo great - but if we are honest then it's virtually as much as you could do with geasv1 after 2 years of development :) He said we want to do a 0.0.1 release before we implement more stuff - we might implement conditions before 0.0.1 - however we must wait for a gnue-common release with gnuRPC before we can release appserver - because appserver depends on gnuRPC. He encourged people to simply test what we have and tell us about bugs :)

Jan Ischebeck noted that At the moment the commdrivers directory is not added if a new release is created with common/setup.py. He suggested that, now the comm drivers were alpha status, they should be added to common to make the use of appserver etc. possible. Jason Cater said It was merely an oversight that setup.py doesn't install commdrivers, and applied Jan's patch.

Bajusz Tamás (btami) said Firebird was his favourite database - becouse it's better then mysql, and have native win32 version. It was, if anything, easier to administer than MySQL, and was only a 2.5 MB download from Sourceforge.

Later, Jan Ischebeck said he had had a look at btami's patch for dbdriver/interbase. It just adds trigger functions (similar to the ones in dbdriver/_pgsql) and won't make the basic driver getting unstable or something like that, so he would prefer to apply it now rather than after the current codefreeze. Jason Cater (jcater) said I've already added it - like 4 minutes ago :)

Jan asked what still needed to be done before the release of common? James Thompson (jamest) said i'd like to look into some issues w/ number fields (common/forms interaction) - but honestly that's looking like next weekend and I want to release so badly. He wondered if claiming that now that we're known for working on GNUe our lives have become one non-stop party might help us attract more developers :).

John Lenton (Chipaca) asked why can't I specify the user in connections.conf? He was getting tired of the login screen. Jason Cater (jcater) said we were, um, being security conscious, adding we were planning to add netrc support iirc. John also noted if you quit a form before the splash has gone away it *hangs* ! Jason said err - we know :( - it's a wx bug and there was both a command line option and a gnue.conf option to shut the splash screen off for that very reason.

Derek Neighbors (dneighbo) said he thought that putting user names and passwords into connections.conf would be a bad thing to do. John said he appreciated the security issues for a live system, but when I'm developing something and I don't have a password on the database in my closed LAN it was more important to be able to get in and out of test forms quickly. Jason still was not convinced, but said if it were added to connections.conf, then GConnections.py is the place to add it. John asked about using netrc instead. James said i would think that netrc would override connections - so the user could override the system default. John said I'm thinking about how to specify the hostname - I think it should probably something like gnue://host/provider/dbname/ - which leaves me with this ugly feeling of netrc not being the right place for it :).

Derek siad that hardcoding usernames and passwords was better done using command line parameters - and alias you shell to always fire those - a command like frmdev aliases gfcvs -u chipaca -p mymomma. John said he did not like this. Derek said he thinks its not a good idea to hard code at all, and that putting it in connections.conf was just as much hard coding as his idea. John said it was hardconfing it - if you put it in your text configuration file, it's the UNIX way. Derek said i would rather see someone work on integration instead - where it uses your system login first - and only if that fails does it prompt. John claimed I'm scratching my itch :) but he would look at that next. Derek said i think with ERP type applications you shoudl be challenged regardless and never trusted but i suppose tehre is no evil in letting connections.conf do it - as its optional. i just dont like to encourage it.

He felt i think a good compromise might be 'remembered' userids by machine. So if i come in and login as dneighbo - next time i fire up forms, dneighbo is automatically entered into the user field - and just have to type my password - but if im not dneighbo i just type my userid and password.

John did a quick fix using netrc, which seemed to work, and submitted it as a patch.

Alejandro Pronotti (aprono) asked How do I do to add an image in a button? James Thompson (jamest) said that that isn't supported for Forms buttons - Daniel Baumann (chillywilly) suggested that the toolbar buttons were hardcoded I think by wxPython. Alejandro also asked about binding a keypress to a trigger? James said at one time this was possible but i'd have to look in the code to see if it still is. He appreciated that there were a lot of things hard coded in Forms, but this was to fit the design goal of forms - we are not building a more generic tool like glade.

Bajusz Tamás (btami) asked can i use firebird or just postgresql as the back-end database with GNUe Application Server (GEAS). Reinhard Müller (reinhard) said that you should be able to use firebird as GEAS now used the database drivers in GNUe Common - however the sql script to load the inital test data into the database does only exist for postgres as of time of writing, although it could be easily re-written for any SQL-92 compliant database. Bajusz asked how appserver knows wich db i use? Reinhard said that the connections.conf file needed an entry adding for [gnue] - this is what made GNUe Forms talk to the Application Server (n-tier) rather than directly to the database (2-tier). Bajusz and Reinhard did some more testing, sorting out various error messages along the way. Jan Ischebeck (siesel) said we need a appserver.conf file soon. I will add some command line options as a first step. The setting to tell GEAS which database driver to use was in geasList.py - but there will be a command line option soon.

Later, Jan asked does appserver needs a special configuration file or should it use gnue.conf? Reinhard said we have to take into consideration that on most installs that use appserver forms/reports will run on different machine than appserver - so i would think it makes sense for appserver to have own config file. Jan suggested putting it into the roadmap for version 0.0.2.

He was not quite happy with the appserver/INSTALL file in its current state. Whats about adding a SETUP, TESTING file or should it be in the appserver/doc/appserver_user_manual ? Reinhard said i think it's ok to have instructions for basic tests in INSTALL - for example say 1. setup.py 2. run test.py 3. run geasRpcServer.py and geasRpcClient.py just as a part of the install procedure to see if the install was successful - anything further should go into doc/manual IMHO. There might also be specific install documentation for CVS versions that is not distributed in releases and explains the g*cvs commands.

Later, Derek Neighbors suggested please make the sql script to load the initial test data as xml under our data definition markup and then it would support more than postgresql :) Reinhard said he had not been aware of this. Derek said it was not fully documented and i dont remember if its in GNUe cvs - as we started it for DCL and adopted it. It used pysablot and sabolotron to convert from XML to a database-specific script using XML style sheets. He explained basically this way you only have to write the table definitions 1 time (in xml) - and the create scripts for all the dbs are created automagically for you. He believed that you could also use it to fill test data or standing data into tables. Reinhard suggested that, for official releases, as well as the source XML, the post-processing version for the main supported databases should be included so one wouldn't need sablotron to test appserver release. Derek agreed - in dcl we even put them in cvs for the same reason.

Christian Selig (lupo_) said he was searching the web for "raw data"->"graph" progs - what are the current output formats of reports? Perry Lorier (Remosi) suggested gnuplot, but Christian pointed out that it doesn't speak svg :-/. Perry said it does speak png, although it would be nice if it output something vector like. Christian said it could output eps.

Batik, from Apache.org was suggested as an alternative, but Christian noted it was written in Java. He noted that plotutils sounds nice, and had not one but two python interfaces - http://biggles.sourceforge.net/libplot/ is the URL for a python libplot interface - and it looks quite human.

Bajusz Tamás (btami) noted some updates needed to the README.databases file, which specified the functionality of the various database drivers in GNUe Common:

Jan Ischebeck asked what is outdated in the py resql description? Should it totaly be deleted? Bajusz said he thought so, as it is DB-API 2.0 compliant now IIRC.

Reinhard Müller (reinhard) asked Derek Neighbors (dneighbo) to please check if the Free Software Foundation (FSF) had received a couple of copyright assignments. Derek was able to check the status straight away, as the FSF was now using DCL for its own internal "to do" lists. He said i think once we get in swing of things with dcl and add some functionality - it will be REALLY powerful for free software projects, including the GNUe project itself. He was not sure why the SSL (Secure Sockets Layer) certificate on the GNUe project's DCL install was showing as expired. However, if people didn't like the default font size, good browsers such as galeon will let you size font to whatever you want :).

Christian Selig (sledge_) asked btw, whatz the release plan? Derek Neighbors (dneighbo) said they had hoped to do a release last week for forms, reports, designer, common, but this had not been possible due to other commitments for team members. He thought if i could find a windows tester we could probably bundle some stuff and check it out - i.e. test it - if it works well we release. Otherwise, i think the best course of action is to probably create a branch for the release - and go ahead and have at head - and when life becomes sane then tackle a release. He noted generally the things that hurt us release wise are getting docs updated and getting things tested - we have a lot more people with installed systems so it should be easier to get 'testers' :) - early releases im not too worried about docs, but they are nice to have - we definitely need to get road maps rolling for all products - with feature lists by release - and use the power of cvs to branch/merge as necessary to not kill release cycles. Previously, this had not been an issue, as not many developers so we could safely not hurt releases. Although documentation was important, for this release i would suffer with minimal docs to get somethign out the door.

Also, we DESPERATELY need debian packages and RPM (Red Hat Package Management) packages to gain critical mass and get over the 'hard to install' hump. He would like to see seperate packages for Forms, Application Server, Common and Reports at first, possibly with seperate GNUe Common packages for each supported database later. There were no technical issues with making debian packages - i need to lock andrew, jeff and nick in a room with some caffiene and computers and not let them out until its packaged :).

Marcos Dione (StyXman) suggested a patch to add a textbox widget to GNUe Forms. Jason Cater (jcater) said he would be worried with the direction this is heading if the intention was to display html markup. After clarification, Jason confirmed that the existing text widget could be made into a text box - set the height="5" - and you get a 5-line text widget.

Derek Neighbors (dneighbo) volunteered to do some testing of the GNUe Application Server (GEAS). Jan Ischebeck (siesel) said if the installer is working without problems, we can do a release of appserver 0.0.1 soon. Derek said not really as it relies on common - or at least it should require common - which means we have to have a release of common in conjunction with it. Jan clarified soon = after the release of common. :)

Derek tried playing stupid user and tried to install using the instructions in the INSTALL.cvs file. He asked does your setup.py in appserver directory check for a VALID rpc driver installed? Jan confirmed this. Derek asked if you run appserver and no rpc driver is available what happens? do you get a good error message telling you wehre to get it? Jan said this was the same as trying to use an unavailable database driver - it raises an error with an url of the location of the driver. Derek liked this idea.

Derek noted that the install file did not mention the changes needed to the connections.conf file to define a connection for GEAS. He got the various GEAS tests working on his system, with just a few minor problems that had already been fixed since the CVS snapshots had been run at midnight (Central Standard Time). He wondered how it managed to access postgres w/o me giving some sort of credentials? Jan said its reinhard's code. It just takes your LOGNAME and set a bogus password. Derek said, based on his testing, i give it a green light success - it might make sense to release this as Application Server 0.0.1 along with the 0.2.0 Forms/Designer/Common releases. Daniel Baumann (chillywilly) did a round of hi fives for the GEAS team, and added wait until it does cool things like objects ;).

There was some discussion about adding support for GConditions before the 0.0.1 release. Derek re-emphasised his point from , saying it was important to start getting disciplined about roadmaps, and using CVS branches for items which were not due until a later release. Jan felt that creating a CVS branch at 0.0.1 was a little excessive. Jason Cater (jcater) said that imho, we need a damn good reason to branch cvs and then remerge - 'cause despite what anyone says, that's a bitch to manage :) Derek said it was more a case of making changes twice. He was open to suggestions, but the overall GNUe project was beginning to get too big - too many developers - too many itches - too many products - to manage on the informal basis that had worked fine until now. He said some of it is we need good packaging and testers - so we can better automate the release process - so developers dont have to devote a week to 'releasing' - as that would help a lot of the problems.