Ariel Calò (ariel_) asked how inheritance will be handled by appserver? There are two issues: First if inherited attributes are redifined as fields in the table corresponding to the derived class or not. Second: if methods are registered in geas_meta_object, and a class inherits a method there is need of a mechanism (like virtual table) to find it. Say 'base' defines 'foomethod()' - there is an entry in geas_meta_object with ref_oid = goid of base. Now 'derived' inherits from base and does not redefine foomethod. Adding another entry in geas_meta_object with ref_oid = goid of base is expensive. Searching for foomethod in base classes is also expensive. This is why vtables are for. Jan Ischebeck (siesel) said he first thought of doing it the python way, i.e. using a __getattr__ function which searches for everything in the base object if an attribute isn't found in the derived object. I like the idea that methods and attributs are stored in the same table. If we would create a kind of vtables, that would mean to copy all methods from base classes into the newly created derived object. Ariel asked it is possible to add another type, say vpointer, to geas_meta_object. The value can be the goid of the method (or field) of the base table. If the method is redifined we add a full entry - if not a vpointer - this is also useful for fields.

Further to , Marcos Dione (StyXman) said I'm working in multiple windows again. I first made a hack that solved the issue of closing the right window, but that isn't enought. He asked should instances be the ones capable of handling several windows? Jason did not think so - he equated Instance == Instance of a form. Marcos had assumed otherwise - in which case he still did not know why multiple forms doesn't work properly. It's something deep into gnue, but I just can't find it. Or wx,.... maybe I should try another ui. However, if he could rely on a form could only be instanced once - that could be cool.

, Several days later, Marcos said he had found what was poking with multiple forms not closing - the UIdriver is calling the wx mainloop as many times as forms are launched. - so the first gets all the events and the rest just sit and wait for somethin to happen. He would send a patch for this to Jason.

Further to , John Lenton (Chipaca) said that to put delegates in I've got to change the api for the dbrivers a bit - basically I've got to have the drivers call the __init__ of dbsig - and then call some other stuff in the dbsig, too. Jason Cater (jcater) asked which drivers - call the __init__ of dbsig? John said not quite, but before doing the update - e.g. in _psql, before doing cursor.execute(whatever) although, thinking about this further, maybe I should just jamm it into the execute :)

Further to , Peter Sullivan (psu) said I've got a revised text for front page - he had put the GNOME ref in the third numbered para. Not sure whether to drop the hyperlink to GNOME, but it *is* free s/w and I suppose we should be promoting it - and there are some people out there who equate enterprise s/w == desktop s/w - so may come looking to us for GNOME-type stuff by mistake.

Further to , Reinhard Müller (reinhard) said if all goes well we will have our own conference room in frankfurt in a hotel close to the LinuxWorldExpo convention centre. At least five people would be there, and i am trying to reach jens mueller (ICJ). Christian wondered could it be that only middle europeans are brave enough to hack an appserver? *g*. Ariel Calò (ariel_) saod he was also considering to join the party.

Some days later, Reinhard confirmed he had booked a conference room with a flipchart and an overhead projector - as well as a modem line - so if anybody of the participants has a notebook with a modem then please bring it. In case somebody still wants to come it's a small conference room but we still had enough room for 2 or three more people. His company would pick up the tab. Jan Ischebeck (siesel) volunteered his laptop - it had a small screen, but Reinhard said that would not matter, as we will need that only to keep contact with IRC.

Sacha Schlegal (SachaS) said when i get some time i will have a look at UBL (universal business language). Its a oasis project which was about typical, common, repetitive business messages - or business data in general. Christian Selig (lupo_) asked if it was a framework for describing business processes? Sacha said it was a bit deeper than that. He thought it could be cool to have .... gnue maybe to support UBL. Christian found a reference that explained The purpose of the UBL TC is to develop a standard library of XML business documents (purchase orders, invoices, etc.) by modifying an already existing library of XML schemas to incorporate the best features of other existing XML business libraries.. Sacha said he believed it grew out of ebXML, I think - so there will be a registry with ubl content and basically you could reference them. Christian asked so, it could be a handful of XML files that you send to a debitors or creditors accountant? Sacha said his interest in UBL was because he was doing a masters by research in computer science on ebXML Collaboration Protocol Agreement formation.

Jan Ischebeck (siesel) asked btw. did you make any progress in packaging gnue? Andrew Mitchell (ajmitch) said uhh, not lately :) that should be something i do this afternoon. Jan asked what the name of the Debian package for Application Server would be, as he wanted to list it as a "suggests" for the php-based Forms package he was doing - /me thinks, that if it is packaged there will be more people who like to test, i.e. bugs will be found earlier.

He asked Andrew where do you want to put share files? Andrew sais probably in /usr/share/gnue/xxxx but i have to check it out with jbailey & nickr, the debian gurus - i have gnue-common in /usr/lib/gnue at the moment rather than /usr/lib/gnue/common, since everything uses code from there :) - it's not going to be pretty. Jan asked what is the best place for the gnue-forms.php script? Andrew preferred /var/www/gnue/gnue-forms.php but that will be ungood for if we have a python or other implementation :) of a web-based Forms client. Jason Cater (jcater) noted that squirrelmail et al put their web stuff in like /usr/lib/squirrelmail - then add an Alias to the httpd.conf file. Just an observation.... don't know that it's correct Jan said he had tried to do it a bit the phpgroupware style, i.e. moving everything into /usr/share/gnue/phpforms. But for now Im lazy, so I just create a link to it in /var/www instead of doing that httpd.conf include thing.

Jan also asked phpforms uses the same images/icons as the normal forms. The easiest way to use these icons is to copy them into the phpforms tree and handle them seperate from the normal forms icons, but by that, they would be at two places in CVS, and possibly in a installation of gnue-forms and gnue-phpforms on one system - so, would it be ok to have the same icons stored at two different places?

Andrew asked if Jan was hoping to get this as an official Debian package into the unstable (sid) distribution. Jan said hmmm, actually I never really thought of that - he had assumed it would be an "unofficial" package. He asked what this would involve, apart from searching a maintainer to ?adopt? Andrew said that, to be official, a debian package needs to conform to debian policy ;) - stuff has to be in the right place, and it needs to do the right things on installation. Jan noted that the php Forms client had never been oficially released and asked if this was an issue. Andrew said hah! - there's plenty in debian that's like that ;)

Further to , Charles Rouzer (Mr_You) said his perl-based Forms client was coming along well - gonna implement the actual buttons/functionality tonight tho, guess it will be reasonably done. The layout engine was working already, but not all the widgets are functional.. just entry and label ;-). The next parts are to add some sort of page ability and db functionality.

Further to and similar threads, Jason Cater (jcater) announced he had done some Debian packages for: gnue-common, gnue-forms-wxgtk, gnue-designer which were available on the website - PLEASE TEST AND SUBMIT PATCHES!!!!! It's my first attempt at debs. He had based them on the Debian packages for Zope. The source code for them was in the GNUe CVS.

The next day, Jan Ischebeck (siesel) reported that they were working great. Jason said he would do similar Debian packages for the other GNUe tools (Reports, Navigator and Application Server), but it was only common, forms, and designer at this point - and I make no guarantees that its 100% Debian Policy :) - but should be pretty darn close if not. Daniel Baumann (chillywilly) asked if he could build the deb from cvs himself. Jason said the instructions are in gnue/*/packaging/debian - you need to do it from a tarball, not from the cvs dir though - but that's as easy as doing a ./setup.py sdist - then the tar.gz file will be in dist/.

Some days later, James Thompson (jamest) said he had moved the debian packages so that they could simply be accessed by adding deb http://www.gnuenterprise.org/debian woody main to the sources.list file. Jason wondered should we send out something to the lists?. He had put them into production on a few machines but still wants anyone familar w/.debs to look at our stuff - as I know they're not perfect.

Further to , Bajusz Tamás (btami) said that the Microsoft Windows versions of the python drivers for the Interbase/Firebird database did not need any dll files - they were just ordinary python files. Jason Cater (jcater) said that mcmillan, the package he had been using to make the python files into a self-contained executable for Microsoft Windows gave an error message about some .dll missing, but he could not remember which. Bajusz noted that one of the python files referenses gds32.dll - this is in c:\windows\system32. There were also refereces in the code for python22.dll or MSVCRT.dll or KERNEL32.dll :) but all of these dll files should already exist on any healthy Microsoft Windows installation running Python. He wouldsee if he could try this packaging myself, using the information in CVS at gnue/*/packaging/mcmillan.

The next day, Charles Rouzer (Mr_You) asked if there would be a maint. release for windows coming out anytime soon? Jason Cater (jcater) said sure - if someone fixes it - /me doesn't have win machines to see the problems :( >From what he had heard of the problems, he imagines thats just the installer, not the actual 0.4.0 release.

Two days later, Bajusz Tamás (btami_) said he had repackaged 0.4.0 for win32 and would upload it as soon as he had proper network access (as opposed to dial-up). designer has some tricky code, so i modified two files and added interbase/firebird and sapdb drivers. Jan Ischebeck (siesel) asked would it be difficult to add a link to the connection.gfd file as a menu entry? This would include an icon in the Windows Programs menu to open the connection.gfd Form Definition, the new form he had written to allow users to change the connections.conf via Forms rather than having to use a text editor. Bajusz said he had not looked at this yet - but making an icon on desktop is easy to any gfd - like jcater has added to intro.gfd. Jason Cater (jcater) said it was important that the connection.gfd was reliable if you are putting it on the menu - /me hasn't personally had time to test it - which is why I was afraid to put it on the menu last release - last thing we need are corrupted connections.conf files :) Jan said he is quite shure, that it works really well.

Earlier, Bajusz said that the two files he had had problems with were designer.instance.py and designer.templates.__init__.py - they grab modules with dircache.listdir, and mcmillan doesn't detect this and include the modules in the stand-alone executable it built of the python files. Many dynamic imports were having problems too. For the moment, he had included a manual hidden_imports.py file, to force McMillan to include all these files. Jason said he was sure this is a bug with McMillan 5 - it is still beta :( - so we probably need to forward some examples to the McMillan authors for a possible bug fix.

The next day, Bajusz confirmed finally i uploaded a repackaged 0.4.0 for win32.

Later, he reported that the connection.gfd doesn't works for me (on win32). Jan said this was because you are using the installer version of gnue on win32, i.e. the connections.conf file is in /Programs/gnue ... instead of C:\PYTHON21\etc\. Bajusz confirmed yes, it works if i use "setup.py install" method - but doesn't with packaged setup. He noted the placement.gfd fails too with 'There are no navigable widgets in this form...' Jan replied yep. The only strange thing is, that it sometimes works ;) Bajusz said maybe it depends from wx version - i remember it woked before for me too - but i installd a newer wxpython. Jan confirmed that placement.gfd works on debian with wxwindows 2.3.3.2 - having webpage which displays on which architecture which testcases ist working (or not) would be great.

Jan Ischebeck (siesel) asked if there was any good free Church Management software. Derek Neighbors (derek) said im writing some - extending NOLA to do it with GNUe. i am youth pastor and church council member for our church - so i have vested interest in it getting done asap. Jan said cool. I thought of using gnue for it too. :) Although there will be many differences (i.e. german protestant church is getting support by the state (f.e. "church tax", etc)) there should still be many in common.

Dan Bethe (ddttmm) said we have several people on the axis team interested in a web based financial accounting package and they're looking at sql-ledger! He would rather use GNUe Forms, and asked if there was any way to have it transparently loaded and launched on the fly via a web browser? a la sashxb? maybe the httpd could look at the binary type of the local http user agent and download the appropriate wxwindows client? and then tunnel or proxy the connection through the browser's ssl? This would give all the advantedges of a web application for deployment and usability issues without the normal disadvantedges. There are lots of people who basically want their web browser to be one virtual workspace as much as possible

Derek Neighbors (derek) pointed out that GNUe currently has a web accounting system called Acclite - which is a repackaging and refactoring of NOLA. The GNUe team had looked at sql-ledger, if only as a basis to build on, but had not been keen. The GNUe developers had been fairly low-key about acclite, as we didnt want to fork NOLA - but last week or week before we said go for it. However, acclite and NOLA had been extensively discussed, as reported in Kernel Cousins, most relevantly .

Charles Rouzer (Mr_You) said that the main problem with web-based applications is that http isn't a persistent protocol so it has usability/functionality problems. From my preliminary searching it would require javascript or iforms or such. to make it appear to the end user that it is persistent, by doing stuff in the "background" Jan Ischebeck (siesel) noted that he had found an XMLRPC library for javascript which might be a good basis for a thin javascript client directly accessing the appserver :). Although GNUe did not support SOAP as of time of writing - they had started with XML-RPC - this would be the next remote communication protocol to be added to GNUe Common. Derek also noted that both Jan and Charles were making html drivers for gnue forms def files.

The next day, Charles asked whether the Javascript license is GPL compatible. I guess Javascript license is lumped in with mozilla license. Daniel Baumann (chillywilly) said that the JS implementation would be with the browser code - which is dual license - with GPL being one option now Later, Peter Sullivan (psu) pointed out that the ISO standard for Javascript was ECMAScript - So I guess that way to phrase it is that a GNUe web client should use a sub-set of EMEAscript that was compatible with both Netscape's Javascript and Microsoft's JScript.

Earlier, Charles said he was leaning toward this: any web-based forms/reports/navigator client needs to be completely written in javascript.. with xmlrpc and http/cgi backend connectivity. I think seisel has begun this, but he said the cgi would still lay out the form, but it would be more portable if javascript did it. To get any sort of persistent-like activity requires javascript/dhtml/iforms - but if possible it makes sense to build in xmlrpc (being done already).. and you might as well buildin form layout. Then for 2-tier connectivity it would require a simple cgi engine. cgi<->db engine. He explained that iforms was some javascript functionality that I looked into a little bit.. for creating dynamic forms. that way, all you gotta do is dump the javascript code onto a web page, and you have a forms client. if everything were xmlrpc. and it seems some people have tied javascript to connect to databases which is interesting, but seems risky. M$ has created libraries for this. Daniel suggested use PSP and Ecma for the gui - less code to write as you can invoke gnue common. Peter agreed - /me thinks the route to sucessful non-python Forms clients is to seek to use GNUe Common.

Jason Cater (jcater) was still not convinced it's a good idea to take a non-python browser-hosted route in the first palce :) He appeciated the need for a web-browser interface of some kind, but GNUe is SO state-based - it will require a persistent backend. He had done some notes on this and I have actually started a medusa client (which is a python-based persistent web server library). This would be persistent on the backend - not the front end.

Daniel wondered if there was a python servlet written in Javascript to allow javascript to run python code directly. Jason said well, actually, there are browser-based python extensions - just like JS - but that's not what I was referring to. Charles said that he and Daniel were just wondering about python-plugin. But I still think writing majority of the client in ECMAscript would be best. then use PSP, ASP, C, Perl, PHP, or whatever for 2-tier backend connectivity. Jason felt that without a persistent backend, that'll be a bitch - as you'll have to load/reload forms - and data sets. Daniel also felt that then you end up implementing a lot of GNUe Common's functionality again. Charles said its mainly just db routines, AFAIK.. Daniel disagreed - common is more than just the db - it is basically our framework - xml parsers, db, rpc, config file parsing, Gobj tree, triggers, etc. base classes for implementing client and server programs too - debuggin classes - db connection handler class - date/time class. But Charles said theres no way you could use gnue-common with JS, AFAIK.

Later, Jan Ischebeck reported that the XMLRPC library is working on both IE and mozilla. Later, he had a bad dream: to port JPython (the code that allowed Java to run python code) to javascript :(

S.anand Nataraj (faqroo) was doing my masters in computers... and was interested in helping with GNUe - i can complete my university project, as well as i can contribute something to a non-profit community... He noted that the web site said that many projects not started.. ex: hr management etc... Charles Rouzer (Mr_You) said that to create application modules you create XML forms using Designer or a text editor. Jan Ischebeck (siesel) said that, as well as XML form definitions, writing applications in GNUe could envolve writing triggers in python etc, writing methods for appserver or database triggers (SQL) ... S.anand said he had heard of python, but never used it. Charles suggested downloading the source code from CVS, and Jan noted that there are prebuild binaries on the website.

Keith Jagrs (KeithJagrs) said that GNUe seems a very interesting project. Do you have any date in mind when it could be ready for production? Andrew Mitchell (ajmitch) said that parts of it were used in production now. Derek Neighbors (derek) said forms / common / designer / reports were all in production use - though reports arent easy to create as of time of writing, they were easy to use. Keith said that the version numbers seemed very low for production use. Andrew said developers here are quite conservative with version numbering :). Keith asked when do you think you will be reachin 1.0 ? Andrew said first we have to decide on what 1.0 will be. Derek agreed, but said 12 months was probably reasonable. Also remember we are not a mickey mouse app in the sense that currently we are maintaining at least 4 or 5 complete tools - designer, forms, common, reports, appserver, navigator, integrator, dcl - so while we might move from 0.3.0 to 0.4.0 in a span of 3 months - that is 7 tools getting released.

Restarting the discussion from , Keith Jagrs (KeithJagrs) asked why dont you use XUL? Derek Neighbors (derek) pointed to the FAQ. When GNUe had started, XUL was not mature enough. Even now, there was a fundamentally different emphasis between the two, in that xforms/xul stuff is web form based - our stuff is data driven from the core i.e. gnue forms are nearly worthless if you arent wanting to 'store' data. The idea of an XUL GNUe Forms client had not been ruled out, but was not a priority for the GNUe core developers.

Keith Jagrs (KeithJagrs) asked do you think the app server will be multi purpose. I mean rivaling with other Python App servers? like skukweb, webware, twisted..? Andrew Mitchell (ajmitch) said that the GNUe Application Server would be mainly focusing on ERP - but there's a demand for more generic, from what i can see. Keith asked whether GNUe Appserver could be rivaling JBoss or Enhydra, then? Andrew hoped so. He personally was using webware at the moment - i've found it to be fairly fast & stable - haven't been using many of the features. Keith felt that python needs to standarize some apps - like to chose webware as a standard app server. Andrew felt that the community can't really do that, since any specific choice would not meet everyone's needs - who knows, GNUe might become the standard amongst GNU projects. For him, the issue was not so much choosing a default appserver, but a set of common standards that an appserver must adhere to. He noted just because the appserver is in python, doesn't mean that code it runs will need to be :) - the goal is to be able to run methods in other languages, as mentioned in the appserver roadmap.

Charles Rouzer (Mr_You) asked is reports going to do graphs at some point?. Jason Cater (jcater) confirmed this. Charles asked that will be dependent on the client building the graph right?. Jason said if client == output processor, then yes. The Reports client would connect to the Reports server if one was in use; otherwise it would talk directly to the database using GNUe Common.

Andrew Mitchell (ajmitch) was trying to do a basic customer form that lists records from another table in a dropdown box :) - mainly mucking around, trying to learn forms properly. Derek Neighbors (derek) said drop the widget you want to store for the customer form - then create a new datasource with table you want in drop down box - then go to the widget and make it a combo box (style) - then go up to its foreign_key/foreign_key_desc fields and put the info. Andrew noted that a wizard to automate this had just been added, but i'm getting python errors - it's picking up stuff but not quite there.

Jan Ischebeck (siesel) had a correction to apply to the 0.4.x releases. Jason Cater (jcater) said that, as of time of writing, the 0.4.x releases were still in effect CVS HEAD - he wanted to do a bugfix release of forms, designer, common within a few weeks for 0.4.1, before branching CGVS to start on the 0.5.0 releases. He would like to include Bajusz Tamás's revised Microsoft Windows executables as part of the 0.4.1 releases. Derek Neighbors (dneighbo) was keen to get some roadmaps for what each version should contain - he still anticipates being able to maintian 'bugfix' versions soem day. Jason agreed, but felt there's not really a "stable" branch of a 0.0.1 tool :)

Daniel Baumann (chillywilly) said that the OdlParser.py code he was writing to allow GNUe Application Server to parse standard ODL (Object Definition Language) files, as previously discussed in , was already 656 lines long - and all it has is the grammar rules. It was getting tedious, but I am close to the end. Andrew Mitchell (ajmitch) asked and then appserver will be singing & dancing object-oriented & omniscient?. Daniel replied heh - not that end, although Jan Ischebeck (siesel) already has a object-relational mapping in _featuretest - sorta. It was somewhat functional already as of time of writing - you can use that sql script - and prime the pump - make rpc calls and play with the data.

The next day, Daniel said he now neeeded to thinks about what the parser would parse into - I was thinking making some kind of AST would be helpful - abstract syntax tree - or do you think one can avoid that step?

Ariel Calò (ariel_) asked what .gear files were for. Jan Ischebeck (siesel) said that it was a zip file containing gfd's gpd's grd's etc. - but you can directly access them, as discussed in . He explained to try it just use the Makefile in gnue/samples to create a samples.gear. Then you can use navigator to access the .gear file and its whole content. Ariel felt that the name is misleading, since it conflicts (semantically) with gear one of the appserver modules. Daniel Baumann (chillywilly) said there's no appserver module named gear - we have GEDI and GEMA - but no gear. Ariel checked, and said he had got confused with the GEOR (GNUe Object Repository).