Jason Smith (jhs) asked how different the latest release version is from CVS i.e. should I even bother with release? Derek Neighbors (derek) said its not all that different as of time of writing, but it depends on your interest in gnue. If you are just wanting quick eval and end user perspective stick with release. If you want to be more 'active' then i would take cvs. If you are on windows i would take release. Jason Cater (jcater) said that CVS was fairly stable as of time of writing, as he had fixed various "oddities" in cvs today - /me is working on a rental property management app using GNUe and it is coming along very nicely/quickly.

Jason Smith (jhs) asked about installation documentation - will the install-from-CVS doc suffice? Derek thought so, but noted there is an 'installing cvs for RedHat doc floating around', but noted if debian you are looking at about a 3 minute install. Although there were no official debian packages for GNUe yet, apt-get install psycopg was a quick way of getting most of the dependancies. Jason said he would probably use GNUe with MySQL initially. Derek said that MySQL was good for web work but serious issues for 'real' work :). He personally was preferring SAP-DB more and more, as discussed in . To install CVS once it was downloaded, from the root cvs directory type ./setup-cvs and answer the questions - and thats it. Try gnue/forms/samples/intro/intro.gfd sample after that. If it works then change entry in connections.conf and try a db form :)

Andrew Mitchell (ajmitch) mentioned that derek seems to be worried about dcl & gnue debs (as discussed in and previously) - especially as there's a security release of DCL due out. Jeff Bailey (jbailey) said he believed there's 0 people using the old DCL debs now. So at least the annoyance of making it upgrade friendly is gone.

Later, Derek Neighbors (dneighbo) asked Jeff to check in what he had for dcl debs. Jeff explained his current debs for DCL were a quick fix for himself, So it's not suitable for checking in to CVS. He could just upload them if necessary. Derek said basically i need debs for dcl (and i know you are busy) - but rather than start from scratch i was hoping to pick up where ever you left off if possible. I have a security release i hope to bundle tonight in tar/gz format and would be killer if i could offer debs at that time as well. Jeff said he would probably have a bit of time tonight to putit together for you. IT's easier than explaining what I've done. Then you're welcome to update yourself after, or have me or another DD do it.. Derek said he would get a tarball to him soon - i have to do some testing still on faq/project sections but if you can package that and feel comfortable giving me something to commit to cvs would be great.

Two days later, Jeff wondered Why doesn't dcl use a makefile like every other project out there? =). Derek said he was not keen on make, but certainly if you need a make file create one. Jeff said Lemme throw a simple one together. I'll cheerfully maintain it ongoing. Since otherwise I'd pretty much be doing so for the package anyway..

Jeff and Andrew tried to work out where the various DCL files needed to go to comply with Debian guidelines. Jeff noted that the Debian guidelines said that web apps go somewhere under /usr/share/doc/PACKAGE/ - That doesn't seem right, though. He had a look at the Debian package for Sourceforge, but that did not seem to be a good model. He decided /usr/share/dcl/www for the web root - scripts under /usr/share/dcl - docs under /usr/share/doc/dcl/ - config file in /etc.

He was not sure what to do with the attachments directory as the DCL application wants to *Write* there. Andrew said this was for email attachments sent thru - eg, submitting stuff to designer-support@gnuenterprise.org, with a patch attached. Jeff considered various possible locations, and wondered about using /var/spool - Esp. if it's a temp holding pen, and not permanent storage, quoting the guidelines that Data in /var/spool represents work to be done in the future (by a program, user, or administrator); often data is deleted after it has been processed. Andrew noted that squirrelmail did something similar.

Jeff also wondered about The templates/custom as if it's not in /etc or /var, it's going to get overwritten on upgrade. Andrew said that templates/custom looks like it is for site-customisation and suggested so perhaps put it in var, and symlink it into the webroot?. However, that'd require apache to follow symlinks. Jeff suggested /etc - I guess the question is it more state data or configuration file? =).

Jeff tried to compile the Debian package, and reported No errors, but some warnings - 6 of which are that upstream appears to have made some files gratuitously execuatble. He reported Right, first cut DCL debs available, adding Bug reports should just be emailed to me, and I'll get them through as quick as I can. Later, Derek thanked Jeff and said he will try to test today and will put a call out on the home pages and announce for testing.

Daniel Baumann (chillywilly) asked where he could find a Debian packages for pysablot, the python wrapper for sablotron, the XML processor that people had been using for GNUe Reports. Jason Cater (jcater) said he had them mirrored, but warned don't ask me questions about xslt syntax - 'cause I'd have to lie. Derek Neighbors had done all of the work on the xsl files for Reports - I've tried to learn it some - but haven't spent much time. He added btw, when I was learning it, the material on the w3schools had the best tutorial.

Derek Neighbors announced There is a new release of DCL mostly covering security patches and some minor bug fixes. It is HIGHLY suggested that you update..

Andrew Mitchell (ajmitch) said it was time for me to learn designer fast - /me wants to throw an basic app together within a couple of weeks at most :) btw, there's no gadfly dbdriver, is there? He had tried to work on one, but was having trouble with it tho :). Later, he reported ok, gadfly driver sorta work now - he just came back to it, made one change, and it partially works.

Some days later, Daniel Baumann (chillywilly) noted oooh, you guys got ajmitch's gadfly db driver :), telling Andrew you are now an author of gnue common ;P Andrew thought this was scary - it's evil ugly code.

Arturas Kriukovas (Arturas) posted the source for a form he was having problems with - he had checked that there does exist database, table, data on it. Dmitry Sorokin (ra3vat) had a problem with date fields - they were getting localized representation which is not accepted by postgres. Arturas said that his work on i18n internationalisation had not included date formats - their format as i remember is coded directly in the source. Dmitry noted that the comments in the DateMask.py file admitted # TODO: This is obviously not Internationalized!.

He asked James Thompson (jamest) is it possible with formatmask(displaymask..) to have datetime data passed always in mm/dd/yy format to a db backend? James said the displayhandlers store in a format different than they display - i don't recal the details. Dmitry said now it represented it in long format with localized weekdays names which did not accepted by postgres. He would like temporary leave it in mm/dd/yy via forms, did it now with export LC_TIME=C.

Daniel Baumann (chillywilly) asked Reinhard Müller (reinhard) if you wouldn't mind if I wrote a schema and odlml xml parser and write some xslt stuff too for the "object" format in the appserver. We can write some transformations to go to ODL. I have been readin GParser a bit and it makes sense. Reinhard said that he personally would probably never use a parser for odlml xml class definition files - he was not sure if it is worth doing but he would not stop Daniel if he was interested. Daniel said well it lets me play with xml ;) - more practically, all the other xml elements in the various gnue formats are GObj based objects, so using an XML-based format might allow re-use of concepts like triggers.

Reinhard said that, working _daily_ with a buttload of different business application _users_ his perception was most of them give a sh*t about wheter something is in XML or in foo - what they want is a stable working usable business software that is easily extensible - to some degree extensible by an _average_ business user. However as derek likes to say "gnue will be all things to all people" - so i guess someday gnue will be ODMG compilant as well as easy to extend and performant and all the other things we want it to be.

Daniel said he was I am just trying to leverage all the hard work that jcater and jamest have put into "common" - seems like what you want can be defined at a higher level, like a business rule design type thing that people can use. Reinhard emphasised this was just his personal opinion, and i might not see all sides of the coin. Daniel said that Jan Ischebeck had been implementing the same ideas in _featuretest plus some of the things he was bringin to the table. Reinhard said he had lost track about what jan is doing as well - and i'm positive we might have different opinions on some topics. He really needed more time and/or sleep to catch up.

John Lenton (Chipaca) said that the papo project team were trying to get the dbsig drivers to work wrt primary keys, as previoulsy discussed in , and we've stumbled over something that'll break backwards compatibility if we fix it - and it's a pain if we don't (because we'll have to check the type of the return value of a function, to start with). Derek Neighbors (dneighbo) said thats ok we have a rule here anyhow it says "You cant fix something unless you break two of something else." John said actually, it wouldn't break anything, except backwards compatibility between dbdrivers - i.e. all the dbdrivers except postgres would stop working - which is fine by me!.

Jason Cater (jcater) asked so what is the fix/breakage? John said in dbsig, you see if the dbdriver has a string called primary key, and you use that as the name of the column that has the primary key - that breaks on one table when you have multiple primary keys. Jason said that the PrimaryIdField was not necessarily the primary key, just a way of identifying a particular row in a table to update. John agreed - it could be for example in postgres the oid. However, the trouble we ran into was when inserting a row that has an autogenerated primary key - we couldn't find out the oid of the row. Jason said he wanted to petition the DB-SIG group to add that functionality i.e., we can get the OID (or RowID, etc) of any inserted rows - but that doesn't solve the immediate need. He had recently added primary key lookup functions to the postgresql drivers in the meantime.

John agreed, but noted that the temporary solution using primary keys would mean that the thing we've got to return from PrimaryIdField is no longer a string, but rather a hash. This was because because, if you remember, we're working on getting multiple tables working... ...so we have several primary keys in several tables - if not, we'd've done "a, b, c".split(", ") and retained backwards compat. Jason agreed - I see where you guys are going, adding just create a trouble ticket saying the other ones might be broken. He said /me thinks the only other driver to use PrimaryIdField is Oracle - and I'll fix it quickly if it breaks as I use it.

Dmitry Sorokin (ra3vat) asked how to get value (for later calculation) of a field in a trigger, just blockname.fieldname returns instance type, not numeric(or string) type. Arturas Kriukovas (Arturas) said in my forms i used like 'print pgName.blkName.entryName' in trigger - this worked (now my cvs copy is broken, so i can't check it). Dmitry suggested oh, may be converting to str first would help - seems , that worked.

He said it seems i'm uncompartible with triggers. Arturas suggested feed them with chocolate? :). Dmitry pasted his code, and said he could not get calc.qnty value printed, but this proved to be a typo. Andrew Mitchell (ajmitch) origianally suggested print "%s" % calc.qnty, perhaps? but then realised hmm, maybe print is not best to use from form? perhaps the forms client is capturing stdout? /me used GDebugMesg. Dmitry confirmed he had resolved the problem, but asked how to exclude calculated field from tab order?. Arturas said make it readonly :), using the readonly="" parameter for the entry tag.

Dmitry Sorokin (ra3vat) said he had a tabbed form with calculated field that works when you insert data row by row, how to get it working when I switch between tabs or run query? what kind of trigger should i add? James Thompson (jamest) said on forms like that i used to create a named trigger then put a post-change (IIRC) trigger that referenced the named trigger on all fields involved in the calculation - that should work for queries. This meant that instead of having the trigger definition on each entry contain the trigger text I just point them at the named trigger. It's been months since I looked/tested that - gnue/forms/samples/button/forms contains named trigger example. Dmitry asked one more question is there a trigger that is fired one time on form's startup?. Arturas Kriukovas (Arturas) suggested you can try with focus-in for the first entry in the form - it should get focus bu default. James said if that works it's an interesting hack - as we don't have any type of on startup trigger but we need one.

Derek Neighbors (dneighbo) said that things were hectic preparing for GNUe's stand at Linux World Expo in San Fransisco in August. He said a. we need marketing materials - b. we need to have them printed :) He thought that Jason Cater (jcater) was probably best situated to design (a) but was not sure about printing. He had got for free a nice display to hold trifoldss - its probably 20x15 or larger clear plexiglass so you can insert your own print - then it has the holder on it for the trifolds. I was thinking if we can get low cost trifold even b/w with a nice insert for the holder i can place that on the main table - as a help yourself kind of thing. Jason said any marketing materials I produce will be available in press-ready PDF for ease of printing.

Problems were reported trying to get GNUe to run from CVS on Debian woody. Derek Neighbors (dneighbo) said that in the root of cvs there should be setup-cvs.py or setup-cvs.sh (i cant recall which) - run that instead and answer the questions. He noted this lets you run cvs and production at same time if needed and gives much greater controll of where things are and such. Later, James Thompson (jamest) confirmed that gfcvs was the CVS version of the code, whilst gfclient was the production/official release. Jason Cater (jcater) confessed /me broke cvs designer last night - /me will fix tonight.

Jan Ischebeck (siesel) asked which command line to use to login + checkout acclite? (as previously discussed in ). Jason Cater (jcater) said we don't have anon cvs for that yet - but snapshots are at http://www.gnuenterprise.org/~jcater/snapshots/acclite/. Jan noted that 'data' and 'database schema' is split into two sql files in acclite. This had started him thinking about the GNUe Schema Definition file which has no way to put some base data into it. (quite ok for a SCHEMA definition ;) ) but data should be stored in an XML representation too. for ease of use I would like to put schema and data into ONE file. any objections, ideas?

Later, Derek Neighbors (dneighbo) said definitely we need to have the 'data' statements as part of our schema spec - its just a matter of definining and making xslt xsl for it. He personally preferred keeping the schema definitions and base data separate as i like to work in sizeable chunks, but im open to debate though. Jan said he would not even mind having each table as a separate file, as long as there is ONE comand to create a whole table set, or if there is one GNUe Schema Definition (.gsd) file which includes the other ones :) Derek noted that well xml/xslt supports includes.

Jason emphasised that I see xslt as a means to an end - not the end itself. In the not-so-distant future GNUe-COmmon's dbdrivers will accept a schema tree and each driver will be able to create the schema natively. Derek agreed - in fact for designer and some other things i almost would like to have it go off the XML schema definitions rather than use introspection to check what was actually in the database - but thats another discussion. He saw this functionality as being important also for integrator as well as designer :)

Jan proposed a simple XML format for data, with rows and values, optionally also with fieldnames, probably as a separate section after the end of the existing </schema> closing tag. Jason noted that GParser depends on there being a single enclosing tag around an entire file (i.e., the "root" element) which would affect where the <data> tags could be placed. Jan wondered whether if we do it that way, is <schema> still the right name for the root tag? Jason thought so, as to me required datasets are still part of a schema definition. Jan said that he would like to use this format as a dump format for the appserver as well, and asked would you object to put "non-required" datasets into it?. Jason said I see no problem with that - most tools like that include an option to dump only schema or schema + data anyway. Jan said he would go away and work out some examples.