Stan Klein said he had been working on updating the security framework proposal I drafted in May 2001, to give examples of real-world security requirements and how they could be implemented in GNUe - at the same time trying to infer what additional GNUe features, if any, would facilitate implementation of the requirements. However, there did not seem to be many examples -- even sanitized -- of real security requirements related to the business processes and data of real enterprises. He asked if anyone could suggest some, rather than him have to I can construct some business process security requirements scenarios from scratch. Jorge Lehner pointed out that at UNI/Managua we just realized an implementacion of Role Based Access Control for the PostgreSQL server, which was downloadable. Stan felt this was important, as In my view, the underlying security has to come mainly from the operating system and database management system. If there is a method of providing RBAC using PostgreSQL, this could probably become a major capability for GNUe to use.

Reinhard Müller (reinhard) said that security for n-tier (i.e. when using AppServer) consisted of several distinct issues:

1. How appserver connects to the database
2. How secure the connection between appserver and database (for example, encrypted, or Virtual Private Network)
3. How the user authentificates to the application server.
4. How secure the connection between the client and the appserver.
5. Once the user has logged into appserver, what access he/she has.

Stan said that Application Server seemed to mean different things to different projects - from GNUe's point of view, it was a mechanism to shield client applications (such as Forms and Reports) from the details and complexity of the data locations and databases or other formats in which the data is stored. As such, Security needs to be built-in from the start. The trend is toward security certification under standards, and Tony Stanco at George Washington University has a project to security certify Security Enhanced Linux, which will be a loadable module of the Linux 2.6 kernel. This will be a pilot project for certifying the security evaluation of a free/open-source software project, which might set significant precedents for GNUe. It was also important to consider security not just in the context of normal operations, but also against specific attacks. If it is feasible to use the operating system or database security for protecting the appserver, we should do so as this would be more secure than "bolted-on" security in the GNUe code itself. However, There may well be some access controls that can only be handled within appserver. If these arise, we should recognize ourselves and make it clear to our users that these functions are insecure against a sophisticated attacker. Paul Juckniess disagreed - Since you may have databases scattered around the net and different operating systems you would really want the security handled within the application in one place otherwise administration could become very complex very fast. Stan appreciated the practicalities, but said Anything you do in the application that isn't protected by the operating system can be bypassed or defeated. The database (which is itself really an application) can provide protection, but the protection it provides has to be grounded in the operating system also. Also, Protecting software written in a scripting language, such as Python, is also a challenge. You need to prevent a malicious user from obtaining a copy of the script, tampering with it by simple editing, and redirecting the system to use the tampered copy..

Dirk Riehle asked Why is GNUe a "meta-project". Is it more than a bundle of the three mentioned projects on the front page of the website. Peter Sullivan said The "meta-" part relates really to the Community aspect, IMHO. As well as the "official" GNUe Applications, anything else written using the GNUe Tools can, in effect, tap into the resources of the wider GNUe Community. This is why GNUe has a much wider scope than most other similar projects (both free and proprietary) - they either focus on providing a toolkit, or "shrink-wrapped" applications. GNUe aims to do both, and more!.

Dirk also commented that he was surprised to see that no implementation work has been done on the actual packages. Am I mistaken or did you focus (almost exclusively) on the tooling/runtime so far? Peter agreed - Although several people are now using Forms "in production" with private applications they have written themselves, the main GNUe Applications have always been intended to use the Application Server (n-tier), and hence there has been little impetus in this area so far.

It was asked what progress had been made on the Small Business edition of GNUe. Bajusz Tamás (btami) said that there was a project page for it on savannah, the Free Software Foundation's free fork of Sourceforge. On the tools, 0.4.1 coming soon and Dmitry Sorokin (ra3vat) noted that the tools is very useful already - forms, reports are tools to build your own application. The amount of "programming" needed to build an application depends on application you need but mostly you do not need programming knowledge.

The next day, Andrew Mitchell (ajmitch) asked how's gnue-sb going?. Derek Neighbors (derek) said good but slow - jcater pounded out schema fixes YEAH - so for now we have the gsd's fixed and working ! i will be fixing the forms to match. Andrew said he had to look at gnue-sb, the description looks like interesting stuff - SB is what i mainly care about - since we don't really have much bigger than small businesses :) in New Zealand.

Two days later, Derek Neighbors (dneighbo) said ok new gnue-sb committed - item management and contact management forms should 'function'. They could be improved a bit and could have more features - but the basic schema's and forms are there and do work! Basically the two custom pieces i had hodgepodged at one time are now functioning. Having pushed for feature maps for the GNUe Tools (as discussed in , i will look at 'feature maps' now for gnuesb.

Later, Derek said he was still holding off a public launch for GNUe Small Business until the issues with the CVS were resolved - it had been given a Savannah CVS web-page at www.nongnu.org in error instead of on www.gnu.org. Jeff Bailey (jbailey) asked Why don't you just have gnue-sb under gnuenterprise.org ? Derek replied because we dont want people to think we have abandoned appserver and more robust SAP R/3 type implementation. However, we needed something QUICK for some specific clients that was two tier and ready to ship within a quarter or two - i.e. read not something perfect with ultimate planning and documentation - but something worked and could be extended.

The next day, Derek confirmed that currently gnue-sb only supports postgres - until the gsd tool is fixed to support the other databases - as soon as the tool renders gsd's for a db that db should be supported by gnue-sb. He personally would not recommend MySQL for use against gnue-sb - mysql is not a kwality kode database for this type of application, nor was sqlite. He noted my personal goal for gnuesb is not to be quickbooks - if someone wants that i will point them to gnucash small business project. If someone is willing to do local filesystem for a db then gnue-sb is bigger than them (imho) - /me isnt opposed to getting sqllite working, but states strongly that is not the target market for gnue-sb. Jason agreed, but said I bet we still see the single business owner strolling in - wanting something for his PC.

Christian Selig (lupo) asked does/will gnue-sb handle european tax stuff - ie tax on sales? Derek said right now this is my big pain - im torn whether to make gnue-sb US only - or support foreign stuff. The problem i have with making it 'anywhere' is you lose a TON of validation rules US business love and speed features. Like if US only i can make it so you enter a zipcode and it auto populates city and state - i can validate phone numbers against states i.e. is that a valid area code for a state etc etc. As soon as i make it i18n i end up with very sloppy validation and very general data entry. /me realizes there is a huge foreign market and doesnt want to discount that. if lots of non us people are willing to help and use likely i will make it i18n - if not then i will likely make US centric as thats my target market. Christian said i think having a market at all is better than fulfilling thousand problematic and inconsistent wishes - if the resources aren't sufficient, we can still fork. Currently i just don't have an enterprise customer who wants to make a switch :( - so i don't have big ERP reality touch :-((

It was asked what a GNUe Schema defintion (.gsd) format was for. Bajusz Tamás (btami) explained its an XML markup for database definition. It was not necessary for building an application, but it is useful for transferring data from one database to another - or filling a database with tables/data. Bill Gribble (grib) explained if you define the database structure with XML, you can translate it into idiomatic SQL for a specific database variety. Bajusz said you can find a good example in zipcode sample - in samples/tutorials/forms/zipcode.gsd - and there is an ooO doc around, but i can't recall where :).

Later, Nick Rusnov (nickr) asked is there like a standard XML database dump format? Like if Iwere to export all the contents of a database into an XML file ... Jeff Bailey (jbailey) said I would just imagine that you'd give each field name to an element and dump. XML is really bad for representing databases, though. You'd have to dump a Schema at the same time to give you characteristics of each field. And XML implies that order is important. Nick felt this was a normal overly-complicated xml solution. Jeff disagreed - It's exactly the right level of complexity. The problem with tab or CSV is that it's lossy. You lose the details that you've asked for about structural requirements in the cell. If you didn't care about that, then tab delimited is probably a better choice anyway. It's easier to parse. The other two cases where using XML is worthwhile is: 1) Occasional Binary data, or data that uses the intended separators. 2) Where you want to remove the relationships and build up complete records using XSLT.

Later still, Jan Ischebeck (siesel) asked a short question about GSD. Derek Neighbors (dneighbo) asked can i ask what you are doing in gsd? we are EXTREMELY overhauling it, which might render anything Jan was doing as moot. He explained we are moving away from xslt to a large degree - certainly it will be supported if someone wants to maintain it. Jan thought that xslt was just the option for all the guys who want to have GSD but don't want to use python. Jason explained GSD is still a standard markup in XML - no more no less - and we didn't want gnue-common as a requirement, not necessarily python - even though, to get it working quickly, I am using gnue-common - but that can be removed later on, allowing people to use sablotron or any other XML processor to parse .gsd files.

Jan, referring back to , said his main concern was why did you decided to make GSD using less datatypes. Jason said it was never intended to support as many as it had - somewhere along the line it got goat-raped and all those things added. Derek Neighbors (derek) said that the original schema abstraction from DCL which had inspired .gsd had one or two more than we have now - but what wsa in cvs got trashed - i.e. lots of datatypes added and support in designer broke - i was in a pinch so discussed with jcater and we documented and revamped back to original vision. I went to make new style sheets for XSLT and decided they were more cumbersome to maintain than a program - so we are making a program. Certainly any XSLT stud could come and modify the XSL to make it a viable alternative - not only do we encourage it, we hope it happens - GNUe is about choice after all. As for tying to common, im not wholly against that as with XSLT one can break that dependency. Jason said our first priority has to be our tools - I want to design stuff that other projects can use - e.g., formats, etc - but that doesn't mean I can put that objective ahead of it being usable for GNUe. Jan agreed. Peter Sullivan (psu) felt it's like the appserver for dotGNU issue - we won;t discourage it but we won;t compromise making AppServer the best possible business application server for our purposes.

Jan said I just have two concerns: 1. how abstract will GSD be? I.e. will it still be usable for appserver? 2. what about gsd->sql generation in dbdriver and gsd->sql driver in scripter. Jason said we wanted GSD to be abstract - not to be an XML version of postgres sql with some translators for other dbs. On the second point, he noted that the scripter is in common - so the dbdrivers can certainly use it - eventually, a dbdriver can take a schema def and actually create the underlying tables - schema scripter (the scripts in debate here) create SQL statements - so the dbdrivers could just call scripter to get the SQL statements to run. Once again, though, in the scheme of things, is not a huge priority. Jan asked if this meant that the scripter would replace the schema writing code which is allready in dbdriver. Jason said that all there was at the moment was a dictionary to give the correct syntax/equivalent to CREATE table for each supported database. Jan asked about the code in common/src/dbdriver/_dbsig/DBdriver.py: _buildTableDefinition etc. Jason said imho this is putting a lot of stuff in dataobjects - I was hoping they wouldn;t get too much more complex.

The next day, Dmitry Sorokin (ra3vcat) asked what gcvs is for? Derek Neighbors (dneighbo) explained it wraps common - so say you write a script myfoo.py that usues common - instead of having to set python paths you can just do gcvs myfoo.py. This was especially useful as of time of writing since the gsd converter uses common but isnt a real script as of yet - gcvs Scripter.py mycool.gsd postgresql > newpsql.sql.

Later, Derek Neighbors (dneighbo) reported a possible bug in the GNUe Schema Definition import code - you had to include a <table name="table_name"> tag to identify which table to create, but if the table specified did match that of the table to import, then the script failed silently. ie the import 'name' must match the table 'name' or the .sql doesnt get created, but no errors are generated. I'm not sure if you meant it to force a name match or not - if not its a bug - if so, we need an error message saying the .sql isnt created. Jason said that was definantly a bug - the parser should bomb off with an error. He fixed this and committed it to CVS.

Bill Gribble (grib) asked are there any plans to provide a gnue transaction processing server, or queueing system? or are most gnue apps tied to synchronous database semantics (i.e. client actions block until complete) Ariel Calò (ariel__) said there are plans for this in the appserver, as discussed in .

It was noted that Reports produced HTML output, and asked how this could used in situations that needed accurate positioning, such as printing an invoice on a pre-printed form. James Thompson (jamest) said gnues reporting tool outputs an XML markup that can be converted to text, html, ps, pdf, whatever - I've had people write letters in word processor of their choice - save as PS file via windows apple laserwriter - then reports can merge data in. Sent out about 600 faxes this way a few months back.

James Thompson (jamest) warned that our win32 support in GNUe Forms via wxPython has issues, we're writting a win32 API ui driver during the next release cycle because we can't get what we need from wx - it works, but it's a bit odd. Bill Gribble (grib) asked so is wx not quite the x-platform miracle it was thought to be? James said i think it's the underlying widget set for the platform - on X we can get ahold of certain events, in windows those events never make it to the wx level. Bill asked is gtk on win32 too far from usability? James said he had not had time to investigate this properly yet - but my understanding is that the gtk2 client is missing some features but is moving along nicely - we're getting lots of win32 patches it seems and gtk2 patches so it may work better than I think.

Later, Derek Neighbors (derek) said i think wx is pretty good xplatform if you have limited resources (i.e. better than anything else) - however its not perfect. I think it has done us well... i.e. quick xplatform to get people interested and get us supported with little effort - now that we have a bigger base i think it will be nice to see naitve, win32, gtk, qt. James said he had added a native win32api Forms UI to the feature plan. Derek said yeah i noticed :) - i think its a good change - i think you are sick for being eager to write one, but its a good thing(tm) ;). James said he wanted to rework the gfd format to seperate layout from logic - btami asked for a feature that would be easy once seperated - so i spoke w/ jcater about it. We decided that the forms documentation wouldn't be that good if we changed the file format right after we release the docs :) He was also writting a GNUe Common usage guide that shows you how to write non-gnue apps with common - should make it into 0.4.1.

The next day, Keith Jagrs (KeithJagrs) asked what the plans were to circumvent the problems with wx under Mircrosoft Windows. James said i know works being done on gtk2 driver which works under windows.....however what I believe you will see in the next major upgrade is a UIdriver based upon win32all - my understanding it that is exposes the win32 api directly which will make for a painfull coding experience but should result in us getting exactly what we require. I have not looked into this really closely yet though (my last copy of the win api book covers the "new" api in win 3.1) :) There were no plans to drop wx in favour of GTK2. He explained that the UI (user interface) drivers were abstracted from the main Forms code - there were already uidrivers for curses, gtk2 and wx - a win32 UIdriver.py could be slotted in the same way. the idea is we don't want coders to have to learn the internals of forms to add a driver - well, not all the internals - they just have to provide code to deal with the events that are passed into a driver. Much of GNUe was designed to be pluggable in this way - our database drivers work the same way and designer also has plug-in system to extend it's capabilities.

Keith asked can curses work on DOS ? Jason said he had looked at curses + DOS - went into "python" on a win32 machine - and did "import curses" - and it didn't work. James was not too worried about text on windows though - personally, i saw the curses thing as usefull for someone running text terminals. Keith noted that there are some companies working with accounting software that runs on DOS. James agreed - i know text apps are used alot in the real world - i myself don't think gui == good by default - however i think a dos text client would be a huge investment in time. Now if a person could find a python module for manipulating text then it would be possible - but doing from scratch would be painful. Jason understood you can get curses libraries for win32/dos machines - so you'd probabl;y be able to custom compile a python binary - I don't have the time to invest in that route but I imagine it's doable. James noted ooooo, if we can get a python binary that does that then our existing packaging will just work.

James acknowledged that win32 support is a big issue - that combined with the desire to work on layout caused us to adjust our feature plans. Jason agreed I think a win32 client will come along very quickly once its started. In the meantime, James suggested setup a cheap arse "server" running the curses client accessing this via telnet w/ putty on the win boxes. It may sound sick but when I go places I spend time looking at their computer interfaces (at stores, companies, etc) - i always ask myself "can forms do that?" - he saw similar set-ups to this a lot - which always strikes me as funny - to spend XX dollars on a windows license to run as a glorified vt320.

Later, James tracked down a web reference to a text-based client - it's not curses but at quick glance it looks like it would provide enough features to make such a driver possible. Derek Neighbors (revDeke) shudders at wincurses - i think your idea of vt100 putty connections to GNUe Server would be more effective :) Jason noted that looks so close to the underlying curses driver that I bet it could be grafted in - so the "widget set" we have created to go over curses could also be used over wcon. He was not sure how it worked however - was it really a DOS screen, or a Win32 console? James felt anyone running pure dos solution would probably be more open to other setups - unless legacy app forced them into it. Jason agreed - if they are in a dos setup we talk them into putting in an ltsp server - and make the dos machines LTSP "telnet" clients :).

J Mozeleski (imoz) asked what ERP backgrounds the GNUe core developers had - whether it was mainly J-BOPS (JD Edwards/Baan/Oracle/Peoplesoft/SAP high end ERP background). James Thompson (jamest) said they had a little of everything, my experiece is with a home grown erp at a mfg plant using oracle and their old sql*tools. GNUe Forms is somewhat based upon the way Oracle SQL*Forms worked - as both myself and jcater like that tool, however we've altered things we hated about it. J Mozeleski said his background was more middle-market, including working for a Great Plains VAR writing custom enhancements for clients. He had been thinking about an open source mid-market solution but after finding Gnue I'm thinking instead of creating something from scratch I could use your toolset to do this? Except I would have to learn Python :-). James said sorta - our trigger system currently only supports python - but quite a bit can be done via designer w/o writting any triggers. Even learning python you'd only have to learn a small part of it - we have a doc in cvs that give a little tutorial on it too - should be in the next release due out any day now.

J Mozeleski noted that Great Plains works virtually identical to this. They have a custom scripting language called Dexterity and a similar forms designer, etc. Same concept of triggers, etc. Of course then they got bought by M$ and are now porting to .NET... Also, as proprietary software, you have to buy a very expensive site license to use the modified code and only dealers get access to the Dexterity tools..

Further to , Andrew Mitchell (ajmitch) wrote a simple csv parser last night that handles quoted strings & newlines - /mecouldn't sleep :) This included writing a special __GetFieldSchema handler to make up field names, or read them from the first row :) Derek Neighbors (dneighbo) said i suppose there should be 3 ways (at least to do schema introspection on csv) - one is the header row(s) define the 'table' - two is a separate flat file defines the 'table' - three is an separate xml flat file defines teh 'table'. Jason Cater (jcater) added four is it could be part of the datasource definition. Andrew siad i thought you didn't want this to be complex :) Derek said im cool with simple and growing it.

Later, Matt Rice (ratmice) asked why a sample form definition contained both a <staticset> </staticset> tag and a <form> </form> tag - it would be much easier if they were seperated so that a single form could work with multiple static sets Jason explained a staticset is just that, static - it isn't updated by a form. Matt said he really needed a dynamic set, but wanted something he could use offline. Jan Ischebeck (siesel) suggested you can use sqllite for that. Jason suggested if you really wanted something even simpler than sqlite - you could use csv files - /me shudders at the thought of doing that with forms - but you could. Andrew confirmed that his code defined a class for a CSV_DataObject that was a STATIC_DataObject. Jason said that was probably correct for the moment - when I was thinking about it that was my plans too :)

Further to , Bajusz Tamás said i have a dilemma - 1. use sitecuspomize.py for setdefaultencoding() - 2. use encoding in every place where it needed - i myself used 1. before ,and i was happy - but today i remowed my sitecustomize.py to test for release and got errors from several places. James Thompson (jamest) asked are you saying we need a way to modify sitecustomize.py during setup? Bajusz was not sure, as Arturas Kriukovas (Arturas) has raised concerns about how this would affect other python applications on the same machine. Jason Cater (jcater) said in production environments, we will probably have a "custom" python install in which it wouldn't make a difference. I don't know what else to do though - without changing all file open() commands to a codec.open(file, encoding='unicode') - which will suck. James did not think a small alteration to the file (prompted for of course) is that big an issue. Bajusz said if we can use our sitecustomize.py with setdefaultencoding() - then no need for many *.encode(encoding) - and python do the rest. The remaining problem, how an install process gets the correct encoding - maybe a popup like in a debian install? James said i think it'd have to be - as this is different from the locale setting isn't it? Bajusz said yes - his own locale was hu_HU (for Hungarian/Hungary) but his encoding in python is iso8859-2 or cp1250 - python can grab encoding from XP/2000 and from LC_ALL in *nix. Jason asked if this was the default behaviour. Bajusz said that this was his custom install - no sitecustomize.py exist per default. Jason felt I really hate that you can't change encoding in your app - that is a really bizarre design decision for python to make :(.

Two days later, James Thompson (jamest) asked how well GNUe was working in Microsoft Windows for Bajusz. Bajusz said that he had not put site.py/sitecustomize.py into the McMillan packages (used to create stand-alone *.exe files for python applications in Microsoft Windows - so i tend to use encodings thing :(. Forms and Designer themselves were reasonably stable, but there were a significant number of event issues which he had raised as collected win32 bugs in DCL :). He had also failed with making forms/reports with simple wizard if i used non ascii title - when i want to save them. James said he needed to move the formFontEncoding code from Forms into Common. Jason Cater (jcater) asked what outside of forms will use it? James asked wasn't designer going to support all languages in its menus/dialgos?.

Bajusz reported huh, finally i reproduced my error :) in Reports. It appeared to be treating the %s paramter literally as an invalid XML tag, rather than replacing it with the value of the paramter - this was without sitecustomize.py. James was surprised it's really putting the %s in there? Jason suggested putting a print statement in to print some relevant variable values. Bajusz said that the debugging print statement itself then errored out - UnicodeError: ASCII encoding error: ordinal not in range(128) - python always wants to convert unicode strings into ascii. This was not normally a problem cose python is clever - but it allways uses unicode in XML. Bajusz realised that Arturas' patch to Reports was not ideal, as it used FontEncoding code originally meant for Forms - but as jamest said, a simple fontEncoding in [common] is a solution. Jason felt that fileEncoding? or textEncoding would be a better name, as fonts per se were not the issue. James asked did we ever get a global section working in config file? to be able to set options like this for all the tools - /me thinks he worked on a [default] section. Bajusz wondered what if someone wants to use different lang for forms and for reports.

Dmitry said he had a mail from python gettext author. He had recommended using ugettext, which would always return a Unicode object, or several other complicated-looking alternatives. Dmitry would forward this to the mailing list.

Further to , Derek Neighbors (derek) noted that people had commented that 0.4.0 windows version on win2000 is very broked (i experienced same) - so if we can get some prelease of 0.4.1 for windows it would be great - /me realizes we are doing native win32 for 0.5.0 - but still we need an interim. Jason Cater (jcater) said bug btami when you see him - he's completely set up to do it fairly quickly. It'd take me a while to get back set up.

The next day, Jason announced New prereleases (-pre3), which included several fixes and Demo-able curses support in forms.

Later, James Thompson (jamest) said i know jcater and I are ready to release - so 0.4.1 may be today if people were happy with the pre-releases. Jason confirmed each of the tools has a ChangeLog - and a NEWS file with an executive summary of changes. Derek Neighbors (revDeke) said that if James wanted any more testing from him on GNU/Linux, that would have to wait until later on. Also, we need windows prereleases - /me is waiting to pounce on btami. James said that he did not feel the need for any more GNU/Linux testing, as i've ran all my work forms thru it - and I'm implementing something today pretty big using just designer and forms. I think we'll be ok - plus I think we've time today - my weekend is iffy at best. Derek empathised, and said certainly release if you feel ready - /me gets to maintain the 0.4.2 release - so if i find stuff and it gets fixed i can always release 0.4.2 :).

Later, Peter Sullivan (psu_) said he had updated the website to urge people to test the pre-releases, suggesting the tag line Pre-releases - when *everyone* gets to act like derek, and we're grateful. Jason suggested Pre-releases - for the derek in you!.

Later, Derek asked you releasing tonight or doing another pre-release - and will there be a windows release for 0.4.1 - or will we be saying windows support is gone until 0.5.0? Jason said he and James were both busy, so it looks like it's later this weekend - though I might stop in and do -pre4's. Derek said his fear is no one has pre-release tested any windows. Jason said I think some were testing under windows.

Two days later, Jason Cater (jcater) and James Thompson (jamest) went on a final bug-squishing frenzy, before Jason announced cvs is being tagged for a release. Derek Neighbors (dneighbo) said jcater/jamest MAJOR kudos to this release - it is by far the best gnue we have seen to date - incrementing the version number just from 0.4.0 to 0.4.1 hardly seems fair. Jason said actually, it was mostly cleanup.

James asked Jeff Bailey we released/are releasing today - any chance we can get new debs marked same version # but 0.4.1b instead of a. Derek asked why cant we use 0.4.1 ? Jeff said that the existing Debian packages, based on CVS, had been designated 0.4.1a and 0.4.1 is lexically a lower version that 0.4.1a, which would cause problems for the Debian packaging system, as discussed in .

Later, Jason warned make sure you are somewhat happy with this release - as cvs will break for a little while (not too long, but it will break). He then did a happy dance as he announced the new releases - Forms 0.4.1, Reports 0.1.0, Designer 0.4.1, Common 0.4.1 and Navigator 0.0.2. Derek said he would do the annnouncements to Freshmeat - Jason confirmed that he had e-mailed the gnue-announce mailing list.

After midnight, Derek Neighbors (dneighbo) noted ok freshmeat updated with all releases - i had to add navigator i guess i never released it at 0.0.1. The freshmeat administrators approved the postings straight away - Derek had been hoping they would have done it in the morning. Freshmeat's biggest audience is US and with a little luck they would stick on the front page till about 12 my time i.e. most of the US audience would see them during morning or lunch break. He noted on days we run releases at freshmeat our web traffic jumps WAY up. Andrew Mitchell (ajmitch) suggested that's when jamest turns the air cooling on for the webserver :).

Later, Bajusz Tamás (btami) and Peter Sullivan (psu) discussed the arrangements for getting the Microsoft Windows setup.exe versions of the 0.4.1 releases onto the website - Bajusz said he would do two versions again, one with the python console window visible (for debugging purposes) and one without.

Two days later, Peter Sullivan (psu) announced btami's setup.exes now on the website. Jason Cater (jcater) was surprised at the size - almost 10MB each. Peter suspected that the extra drivers (sapdb, firebird, etc) are the main causes of the bloat. Bajusz confirmed that the setup.exes included GNUe Reports as well, now that this had reached version 0.1.0. The main reason that the files were so big was the inclusion of wxPython, which was 6MB all by itself, rather than the database drivers.

Derek Neighbors (revDeke) said he might need to do a few point releases of 0.4.x, depending on how long James and Jason took to do 0.5.0. James Thompson (jamest) said most of 0.5.0 shouldn't be major, we've been looking into it - it'll be major on the user visible side of things, but internals shouldn't kill us. Derek was thinking the win32 driver and curses drivers will be the biggies - not necessarily in 'dev' time but in testing time - assuming basic curses support didnt make it into 0.4.1. James said i'm pretty sure it will be _almost_ feature complete for 0.4.1 - but I haven't tested in a few days. Derek was impressed - i dont think it needs to be 'complete' for 0.4.1 just like i dont think win32 would need to be complete for 0.5.0 - but more 'reasonably' complete 'first preview' give us lots of feedback :)

James said i imagine 0.5.0 will have the new gfd format and maybe the start of win32 - the new gfd format will be a HUGE gain for forms - as you'll be able to do l33t things in it due to the complete seperation of layout from logic - you'll be able to mirror fields on multiple pages, mix things about any way you like. I think 0.5.0 is this year - it's become an itch we've got to scratch - you should get a layout manager system as well. Keith Jagrs (KeithJagrs) noted there's only one month and a half left to new year's eve. Jason Cater (jcater) said our history is to release either right before or on a major holiday. Derek agreed - well 0.5.0 before end of Q4 02 would be great - while there are lots of holidays generally that means time off work - which means to a degree gnue time :) He was worried about this gfd switch - will we have conversion tools? or open in design and save - /me is only worried as im getting ready to do a boat load of forms. James said yes - I think we're pretty good about changing things and hiding it - it's worth it in any case - this is something I wanted from day 1 - it's how sql*forms from oracle did it. Jason said jamest and I were discussing and decided we really couldn't wait any longer - as the closer to 1.0 we get, the more stable the gfd format must be - so if we are going to do a "correction" in our format - we better get it on!. Also, James pointed out that they were planning much more documentation with the 0.5.0 releases, so would rather change the format before documenting it rather than after! He had always wanted to seperate the logic from the layout in gfd - when I started I wanted something out the door fast - so I blended them which was a bad, bad thing - but it was quick, i was just learning python while coding, i was young and needed the money. Nick Rusnov (nick) sympathised - we've all been domn that route - but you end up just spending all your money on gold chains and skintight pants.

Jason noted you realize with this separation I will quite literally be able to do a converter to get existing Oracle SQL*Forms working as GNUe Forms instead - the only other issue was Oracle's specialist PL/SQL trigger logic. Derek said well i think ultimately we will be better than sql*forms for many reasons James said we are better now in many respects. layout they have us - stability of the painter they had us - abilities of the painter we kill them - painter = deisigner But forms is more powerfull than their client IMHO.

Later, looking at the feature plans, as discussed in , Derek Neighbors (derek) asked for forms what happened to 0.4.1 release? we should leave them on there as complete, no? - i think it makes for a nice history as well. James said that the feature plans start w/ 0.5.0. Derek said there are features that are missing (i assume these are possibly not comprehensive) - in which case i will throw out the feature and you all can determine where it best fits. He emphasised that it was up to James and Jason, as the main coders, to decide which version a feature belonged to - i.e. you could say we will never support that, we will support it after 1.0 sometime or yeah we need that lets decide where it goes. James noted that he and Jason were looking to tidy these up as part of the 0.4.1 release anyway - they knew there were some duplicates and inconsistancies.

Derek asked what is grid view mode? James explained it converts a std form to look like pgaccess - it's a 'shut up users that keep asking for pgaccess on my systems even though pgaccess is slow and buggy' feature Derek asked about a a native grid widget to replace the current rows="10" functionality, as discussed previously in many threads, as far back as . He realised this was mostly cosmetic, but again this is high priority it could be post 1.0 - but thats what im asking ... should it be pre 1.0 and if so, how pre 1.0 - im thinking the blocks/fields things might make it easier to implement. He also questioned the need for a qt driver pre 1.0 - ideally he would like to find a volunteer from outside the core developers to write this like happened with gtk2 one - i.e. i would like to see a qt driver - just hate to see critical resources on it, again i understand the scratch an itch so its comment not a complaint.

He added most of my other stuff was questions for designer, but looks like its plan isnt produced yet. The three things i have there

1. good mask editor
2. starting of schema editor
3. trigger editor capabilities
4. cvs integration
5. project capabilities
6. gpd editor

Andrew Mitchell (ajmitch) said a good mask editor could have a set of preset masks to use. Jason said there was already some functionality for this, but it needed some more polish. The way it worked at the moment was that you defined a format in the gnue.conf file, and could then reference it from GNUe Forms Definitions (.gfd).

Derek also asked for a calendar picker for date format fields - i think about every platform can support as well - i see it as nothing mroe than attribute of entry of some kind. James was not sure of the need. Derek gave a practical example - im planning airline travel - i want to travel week of christmas - i want ot leave monday before christmas and return friday after christmas - do you know those dates w/o looking at a calendar? unfortunately i dont - its much easier for the application to show me a calendar than to hunt one down :( Andrew asked hmm, when was wxCalendarCtrl added to wxpython? is it in 2.2.x ? :) Derek agreed it was not a high priority thing - it was one of those ithink we need, could be post 1.0 pre 1.0 thats your call. James wondered if this would be better done as a plug-in. Derek felt this was pretty core, but im not opposed to abstracting it so that other things can be done as well - i.e. i realize there will be lots of similar requests some we agree with some we dont.

Andrew, after carefully donning a flameproof suit asked what sort of timeframe are we estimating for these releases? :) Derek said there was talk about trying to have 0.5.0 by end of december early january if real life (tm) treats everyone well - i think predicating anything beyond that for other releases makes little sense.

Marcos Dione (StyXman) was finishing the merge to include all the changes to GNUe's CVS in Papo's CVS. but I want to be sure we didn't break anything. should I use the samples to test, and that would be enough, or are better test somewhere else? James Thompson (jamest) said i think the samples are fine - once you've merged can you get us a list of differences between your code and ours.

Later, Marcos noted that almost all the DBdirver.py's have the same $driver_DataObject_Object._buildQuery method - they're all the same (ok, just the first few ones). Derek Neighbors (derek) commented good eyesight you have young jedi. Marcos suggested why not move it to DBSIG_DataObject_Object or above? Jason Cater (jcater) said if you look closer, they can't be moved up - this is forcing the DO to not run the parent's DO, but a second parent's one - /me remembers hating to do that, but it was necessary. Marcos noted he had to change this in each of the 16 database drivers.

Some days later, Marcos asked what would be that 'kstructural changes'that you tal about in (one of) your last commit? Derek Neighbors (dneighbo) speculated evil doings :), mainly the seperation of logic and layout, as discussed in . This made it even urgent to merge our trees (i had hoped you would have merged for 0.4.1 release) - but if you guys dont hop on it in next day or two it will likely be really BAD - i.e. the guts will change significantly and merging will be near impossible. Marcos said I can send the big patch *now*. James asked does it have to be one huge patch? Marcos said he could (try to) separate it in functional patches but that would take some time. James said to send it anyway. Marcos disclaimed some features added are maybe deprecated. those you think are ugly, pleasse feel fre to discuss them either in your mailing list or in ours. Marcos sent the main large patch as a single 143k diff file to James for review.

The next day, Marcos noted that the simplest of our patches had now been applied to the main GNUe code tree. James said he had some queries on the other parts of the patch. Marcos explained that genericBox is for asking questions with more options than 'yrs' and 'no', whilst atomic* is to make sure only one person can modify a what-would-be-called database register at a time. James asked could the same result be accomplished by adding an atomic="" to the datasource tag? Marcos said it was more subtle that that - by applying it to an individual entry, only that entry must be atromic. the others may not be midified atomically. This was called from a trigger - he pasted an example. James explained the reason I ask this is that we want datasources to support record locking which this appears to be - if we were to add a atomic or locking="" attribute to a datasource that locked records after they were modified - would that serve the same purpose? and I think it may require less work on the trigger writters part :).

Earlier, James noted that function calls in python are a hideous performance hit - we switched from a getFoo() to self._foo with the _ meaning private. They had not realised this at first either! Later, John Lenton (Chipaca) said how is less than 10% a major performance hit? or, how is less than 10% reason enough to through the whole OO thing out the window? James said that 10% isn't much on occasional calls but our UI system had lots of such things going on. Jason felt that self._form is as much OO as self.getForm() - just maybe not by the java definition. John said I have no problem wiht self.form, in fact, I kind of like it. It's the /^_/ that bothers us, as that is always an indication of "this is private" - and in fact you agree - but then you expect people to call that, so it's no longer private. Jason said that the underscore prefix in code was used to indicated that something is considered to be a settable attribute - ala XML files. It was only in the context of the connections.conf config file that it meant "private." James said i don't think we have a hardfast rule on private.

Earlier, James asked whether they had got scrollbars working with gridlayouts now?. Marcos explained scrollbars associate to its surrounding block. - they 'register' to them - so, when the data source is updated, and the block is notified, the scrollbar gets updated too. what I can't make work is 'free scrolling'. wx is very ugly reporting these ind of events.

James also noted you exposed some gnue internals via some of those trigger functions - i was wondering why? i know we did hacks like this at one time - but started to try to move away from them as internals can change and will alot :) So if we can figure out what is making you have to drop to internal levels we can adust the code - every time I've done this the workaround makes the triggers easier to maintain :) He was aiming to get a fair bit of this in for 0.4.2 but not all of it - as I'm pressed for time and have other bugzzz to address ;)

Marcos said I guess you're also puzzled by that history tables thing... Derek Neighbors (revDeke) said i think your history tables need to be implemented as tables and triggers and not embedded in forms (read hardcoded) - i had same need for gnue-sb - was going to do all in triggers though there has been talk of making some 'convience functions' for such things so triggers would be nice and clean. To save recoding the trigger for every field, you should be able to make it a shared trigger and just reuse it. Jason said that they had not wanted to use papo's solution as the general GNUe solution for transaction/history tables because we can't have harcoded schemas in common. Derek agreed - not everyone wants it - and HARDCODING it is not a solution. Marcos said we done it that way because appserver (what would like to use) was not available when we started coding things in a stable version. But he felt papo we can live with an external patch 'till we recode, I gues....

Derek said that after this merge there will need to be some ground rules. He wanted to avoid papo having to maintain a seperate CVS, and would prefer patches function-by-function, rather than mega-patches like the current one. Marcos agreed - remember that the patch was sent 'as is', as I had no time to filter out what I thought it won't get anyways. Derek said we are willing to do what it takes to merge the repositories best we can - but we dont want 'resyncing' to be a regular thing... we want one repository and patches :) Marcos, as the person responsible for re-syncing, was fully in agreement!

Later, John said We really, really need some way to tell when it's ok to go in and use the stuff and when we must write an accessor for it. Jason said if there's not an accessor now, then we didn't intend for it to have one. James said if it requires any type of logic at all to get what you require then you need an accessor.

Earlier, Derek emphasised that quibbles like this on papo's patch was not a rejection of the functionality - just some concerns over how it had been implemented. James agreed - dude, there's some cool stuff in that patch - I'm happy to see a working scrollbar setup for example, and you're menubar patches inspired jcater to add trigger to flip them off and on (I think). Also, the whole atomic* stuff has me seriously looking at replacing the TODO lock record here crap in datasources.

Earlier, Derek wondered if some of the issues with the patch were just a matter of personal coding style - like where to put braces or how much indentation to use. John asked about indentation. Jason said we are actually *very* standardized on indentation... any variancies are oddities that someone likely committed - we do two space indents, with no tabs - I don't think we want patches that do nothing but fix indentation levels - but that is what we try to code at. John said he would make this the standard for future papo patches.

Later, Jason asked what the new <entry style="textlookup"> was for - it seemed to be just the sames a label. John explained textlookup _is_ a label, except that it goes and fetches the labelee in a dictionary table - rather like a cross between label and dropdown - the name might be less than perfect... but we couldn't find anything better :). James asked how large are the dictionaries this thing is pulling from ? John said it was typically used where doing a normal query would involve bringing back many rows of un-needed data. James agreed - if we did this via a normal datasource with prequery="" and the result set it huge we kill memory (a shortcomming on our end) - but if we're scrolling thru a partlist and it's having to pull the values each time from the backend the UI would get choppy (a shortcomming of the way you've set it up, i think). However, our datasources already have a very stupid cache system built in which could help. Alternatively, this could easily be accomplished as a post-change trigger via the simpleQuery function (i think) or could we merge the concepts and use the datasources for now and concentrate on improving the cache system in datasources long term. Jason said that, for *this* particular case, the first way of doing it was the best although I do want to see cache system improvements.

Jason also suggested using the "foreign key refresh" functionality recently added for dropdowns, triggered by the on-change trigger. John asked how this would work. James suggested it'd be a style=label with the same attribs as a dropdown? John asked wouldn't that amount to overloading of label? - not that overloading was necessarily bad. James said this allows a uidriver that doesn't know how to deal w/ style=dropdown to still display a normal entry - such as the old, forgotten curses driver - it didn't do dropdowns but it did handle entries - our sample form had a dropdown where I could select Kansas in the dropdown - the text client let me type ks, degrading gracefully.

John said that another reason for not fetching everything is that these things might change between the first fetch and the time one wants to display them, so in effect you have to fetch it every time anyway. James agreed - /me understands that you want the field to update if the backend data changes. John said this is taking one more step down the road of "dropdowns need their own datasource". Jason said this was the case anyway - all references to a database are done via a datasource - when you consider what all else datasources can do this opens up a lot of possibilities - e.g., with our static datasources - we can have combo boxes that pull from a static set of values defined within the form, not pulled from a table - that's just one example - remember we are abstracted from a relational database.

The next day, James apologised for not getting more patches applied yet. Marcos was not worried - he said he had printed off James' comment about "some cool stuff in that patch" in big black letters - we're gonna get that sheet of paper framed :).

Peter Sullivan (psu) said I have added a "Get Involved" page to the website - mainly for a link to a good external article Jason Cater (jcater) wondered does it involve "Send donuts"? Derek said we need a HOW DO I HELP PAGE - as that is number one question we get at info@gnue.org - hmmm this page might do the trick :). He asked for the contact address for documentation bugs/patches to be changed to docs-support@gnuenterprise.org rather than info@gnue.org, so they would feed directly into DCL via the e-mail gateway. The other thing we need if it doesnt exist is either a 'license page' or better yet right on the home page - add somethign that says gnue tools/packages are GPL - as i know my pet peeve in getting new software is hunting down what license its under before downloading. We make lots of reference to freesoftware and even fsf, but i dont see clarification where we state we are GPL Peter agreed - most people should hopefully be able to guess that GNU* == GPL, but why not tell 'em outright? He would add it to the front page.

Andrew Mitchell (ajmitch) suggested you may want to reassure people that using GNUe doesn't make their stuff GPL - as i've heard people worry about that before (interesting problem there). Derek said true... maybe point to gpl faq as well. Andrew asked applications that hook into GNUe common, what license would they fall under? Derek said if you used common via 'import type statements and such' i think your resulting application would need to be GPL - if you used it via RPC it could be anything you like as you were simply using rather than linking to the code.

Derek Neighbors (dneighbo) suggested that the Debian packages should eventually be structured with a gnue-forms-base, with a seperate gnue-forms package for each user interface - gnue-forms-gtk2, gnue-forms-curses, gnue-forms-wx, gnue-forms-html etc, each with their own dependencies. Likewise, there could be a gnue-common-base and then seperate packages for each database driver - to give people finer grain control of the install. Jeff Bailey (jbailey) agreed - I think that's the plan. certainly for forms anyway. The hard part with doing it too much is that people will never figure out what to install. Derek suggested couldnt we do something like task-gnue - for the people that dont want control.

Derek Neighbors (dneighbo) continued to make progress on the item maintenance screen for GNUE-SB. He needed format masks, but according to the Developers' Documentation, it looks like masks arent quite there yet. He just committed the item_maint.gfd that actually manages the items - so item management is now officially in gnue-sb cvs - its basic but its a start.

Later, he said he had worked around not having format masks for the moment, but wondered where this fitted in the Feature Plans - we need to add number/currency format/input masks - and documentation of masks :). Jason Cater (jcater) said input masks are a BIG todo - we are very close - but no cigar quite yet (that should be in 0.5.0 plans, if not, I'll add), although most of the backend is in there.

Derek Neighbors (dneighbors) said we need an easy way to do transaction stamping i.e. createdon/by, modifiedon/by. Jason Cater (jcater) said there was a REAL easy way to do transaction stamping - they're called Pre-Update and Pre-Insert triggers - same principle as setting the sequence value on an insert. James Thompson (jamest) said no, we need a real, real way :) - just like the getSequence function, you also have getTimestamp.

Coincidentally, Derek then came up against a case where he needed to use getSequence - the classic 'the parent needs to create its id in order to store in the child' problem - do you have a sample form that this works in currently? Jason asked are they set up as master/detail? as it does all that behind the scenes if so. Otherwise, check the recipe's chapter in the dev guide.

The next day, Jason said we have a createdon recipe - but createdby - who is "by" ? James said i think he wants the username of the logged in user. Derek agreed - he wasnt sure how to get that info via trigger. Jason said I know we can do that via triggers - but we probably need to add a convenience method. Derek asked what if you are using a custom 'authenicator'? He had had to make all my 'transactional' stuff like that nullable for now in gnue-sb - until i get good trigger way to do it (or a convenience method) - then i will add it back in. /me thinks the date part is taken care of - if the db is setup properly then the "created on" field should use function that posts timestamp if null else nothing if there - and the modified should use function that posts timestamp no matter what - though it would be better to amke it in application i think.

Andrew Mitchell (ajmitch) said he was trying to get a form to work - like automagically inserting sequence numbers for master/detail. James Thompson (jamest) said that should be in the docs as a recipe IIRC. Andrew noted mysql's auto_increment doesn't work for master/detail, nor is it friendly :). James suggested i think if you implenet sequenceNumber in the mysql driver then you'd have them - i _think_. Andrew said all i want is for the primary key (id) to be set for each record :) - and the value being set to be visible to the detail portion. James said that's automatic on a commit in common - however getting the initial value from the db isn't IIRC - if you do the assignment on the database side then you have issues IIRC. He suggested a db side trigger or a default value set to a function. Andrew pointed out triggers? what's that? this is mysql i'm using :) James asked how the primary keys were being generated. Andrew said at the moment, i have the primary key field set to auto_increment in the db - which sucks. James said hey! auto_increement == db side trigger! see, it's more advance than i give it credit. Jason Cater (jcater) asked do you know the name of the sequence it created? Andrew did not think that sequences had names that could be referenced in mySQL. Jason went googling for the answer.

Daniel Baumann (chillywilly) said the lesson here kiddies - mysql sucks ass. Andrew said he did not have much choice as he was developing something for systems already with mysql. Daniel suggested using the GNUe Schema Definition (.gsd) format to migrate to another database.

Andrew suggested that it would probably be easier for me to get the current id value, increment it, and save it back - this would work with even simpler databases like sqlite and gadfly. James said the only sensible solution might be to get the GNUe triggers to handle assigning the primary keys - create a table gnue_seed. Jason suggested that, or select max(id)+1 from table; James added then make the getSequence in the db driver read the seed via a select for update, update it, then have it print to the debug log "compensating for the lack of a sane database". Andrew commented that he would have thought this would be a 2-minute thing with mysql, at most.

James Thompson (jamest) warned stay away from cvs head - it should still work but jcater has commited the start of changes for 0.5.0. I will be branching 0.4.1 tomorrow to apply some patches and will be releasing 0.4.2 of at least forms later in the week.

Later, Derek Neighbors (derek) asked is new gnue in sid? Jeff said No - Maybe tommorow or the day after, or maybe a bit longer for technical reasons to do with marking it as suitable for all/any of the Debian architectures - as a python application, it did not have to be recompiled from the i386 version of Debian to other versions. James Thompson (jamest) said i hope to have a 0.4.2 out later in the week or early next - to address some issues and include some of the Papo stuff. Jeff noted That will solve the versioning problem nicely, then. He asked Are the versions in CVS now going to be lexically sane from then on?

It was asked whether GNUe would be a suitable replacement for Access for someone desperately trying to break their M$ habit. Jason Cater (jcater) said we are not an access replacement, per se - but could definitely be a substitute - we are comparable to the Forms and Reports parts of access (only with a lot more power, imho) - we don't have a database, so you'd use PostgreSQL, for example, as the database backend (or SAP-DB, ....). On the programming side, he said we use Python for any triggers/events... it's a VERY newbie-friendly language - it would be a small step from Visual Basic for Applications (VBA) to Python.

Later, Derek Neighbors (dneighbo) added always someone coming from msaccess - suggest that pgadmin has a MIGRATION tool - that will migrate all tables + data for them from Microsoft Access to PostgreSQL - which is a huge part of the work if they have not done anything too 'fancy' code wise (standard vb forms) - designer will putty in their hands especially with wizards. /me has half considered writing a vb forms (and delphi forms) conversion tool. He added the biggest thing we are missing (and so is pgadmin) is a 'query designer' - i think eventually it would be nice to have that in designer(schema tools). If you all add the quick table view stuff (what someone was calling grid view) - the 'query designer' would be about only thing we are missing to be close to access replacement (imho) - and unfortunately i have seen a LOT of access ;)

Dmitry Sorokin (ra3vat) noted that encoding param in gnue.conf is only relevant for postgresql - so it understand specific pgsql names - encoding is the client encoding and could have various values for normal ASCII or other specific character sets. Jason Cater (jcater) thought that belongs in connections.conf if its specific to postgres - actually I thought it was already there? Dmitry said this dated back to before there was a separate connections.conf file, and agreed it should be moved. So did Arturas Kriukovas, who said i would like to believe there was some reason why i did put it here, but i don't remember :\ - he would fix it in a few days.

Dmitry Sorokin (ra3vat) asked what is caption attribute for page? Jason Cater (jcater) said for notebook pages, that can be the notebook tab caption/label - if missing, and you have a notebook page, caption defaults to the name value. Dmitry asked what does transparentBlock attribute mean? Jason explained this controlled the behaviour of the tab key - If you are on the last field of a block and there is another block in the form then if transparentBlock is true a tab will take you to the next block - if false it will take you to the first field of the same block. Dmitry asked how you could get to the other notebook tab in this case. Jason said the Page Down key always took you to the next tab - for triggers, I think you can do a form.setFocus(otherBlock).

Dmitry Sorokin (ra3vat) asked how to set scrollbar over myltirow entry? James Thompson (jamest) said our code doesn't support scrollbar's yet - papo guys seem to have it as part of their patch - if time permits I'll be going into the 0.4.1 branch - and then into head. Dmitry asked it seemed to me you did some work on scrollbar already? James admitted i added the code it display it but never tied it into the event system so it would respond to mouse clicks or key presses like a "proper" scrollbar.

Nick Rusnov (nickr) asked theres no way to express in SQL the kind of uniqueness that says 'the combination of these two columns must be unique' is there? - like a constraint but instead, this row is uniquified by two columns instead of just one. Jason Cater (jcater) asked isn't it just "unique (field1, field2)" James Thompson (jamest) agreed - you can create a unique index on 2 fields or setup the primary key constraint at the end of the table def instead of behind one field. Jason noted that there was a distinction between unique and primary key - unique does not enforce nullness like primary key does - so if you want "unique and not null" you need to specify not null for those columns. He used multi-column unique constraints quite often - example, we sell magazines - so we have a table that holds our offers. it contains the magazine id and the number of issues - so only one combination of (magazine, issues) can exist in that table. there can be plenty of 12 issue magazines - and plenty of offers for People magazine - but only one offer for People at 12 issues.

Bill Gribble (grib) asked have you guys thought about working with twisted? seems like there could be a lot of redundancy between gnue and wtisted. Derek Neighbors (revDeke) said i think we existed long before twisted so one should ask why isnt twisted working with us :) - specifically they iirc are much more web oriented. Likely the appserver team would be the best to address 'twisted' stuff. Bill said seems like there's mission overlap but not enough to point a finger and say somebody's wasting time. they don't handle any of the forms/reports/etc, just the wiring and app-service. Derek agreed - i think they are more similar to our appserver than gnue as a whole - i think jan or jcater mentioned offering an appserver provider for them or something. Bill said anyway their stuff looks pretty interesting. it is sort of kitchen-sinky and the code/doc ration is a little high but I think there's useful stuff.

John Lenton (Chipaca) asked why Derek Neighbors (revDeke) had started gnue-sb as a seperate project, rather than working with project papo. Derek said he had understood that papo was aimed specifically at the Argentinan market and was in Spanish. John explained the PAPO team's medium-term objective is to replace an Argentine-specific ERP. There is, as far as we know, nothing in the design of PAPO that's Argentina-specific - the screens are in spanish because that is _our_ target audience, but internationalisation was planned for after November. Derek said that when i looked at papo it wasnt what i was after - specifically you appeared to be making what we want final GNUe to be - with gnue-sb we plan to be much simpler than what official end game gnue would be - specifically there is no intention to use appserver with it - if you think we can work together great. John said that papo had been started as a seperate project, as the GNUe tools were mostly there, but the packages were a *long* way away of what we need. Derek agreed - that was why he had started gnue-sb.

John said that papo was pointed more towards small-to-medium organizations, while gnue (as it name implies) is aimed at fully fledged enterprise-level stuff, that is, IOHO, over papo's head - which is why gnue-sb called our attention... it seems to be more or less what papo is getting to be. Peter Sullivan (psu) said that some of the discussions about adding functionality to the Tools had indicated that papo has compatible but different way of approaching things - this wmight have been even worse on the Packages, and lead to a fork. He asked whether papo's long-term goals included AppServer. John said long term appserver is by far the cleaner approach, but there is nothing wrong with 2-tier if the needed functionality is hidden away in dbsig, for example. Peter felt that the overlap, if there was one, was between the GNUe Packages and papo rather than between gnue-sb and papo - but this had always been recognised. John felt there are some rough edges between what papo aims to do and what gnue seems to aim to do, mostly related to who the intended users are, but those are all confined to the UI AFAIR.

Derek said that papo appeared much more geared to 'manufacturing' - my needs are more on wherehouse management than assembly line, which was the focus of gnue-sb. But he had no problem working together. John said that papo's entity relationship diagram (ERD) tries to contamplate SB product mangling, but that's about it - he was going to set up a friendly web thingie to browse our ERD, as it is rather huge. He used Zot for ERD documentation, and was even considering writing a zot2gsd to enable GNUe Schema Defintion Files (.gsd) to be automatically converted from Zot.

Derek said that the point of gnue-sb was to ramp something up quickly - /me doesnt have time to debate argue and make things feature complete for the world - but rather something that is usable and shippable and easily extensible - so while i have no problems working papo or other projects, very much gnue-sb is a [no] nonsense 'get it done' application. The alternative approach - long toying with trying to incorporate a ton of varying opinions - that is what GNUe official packages will tackle :)

It was asked what the current state of the console version of GNUe Forms was. Jason Cater (jcater) said very close, but still a few issues - I am looking to design gnue forms and have a curses based forms client. There were some screenshots some screenshots from a couple of weeks ago. Current issues with curses: button support hasn't been finished, no notebook page support - um - and a few other small things - but it's VERY close. I can actually use it to edit and save data. oh, yeah, the menubar doesn't work - that and the buttons are the biggies right now.