In the midst of several Star Wars spoilers, Jens Müller (ICJ) asked about package management, noting dpkg or rpm certainly have good routines concerning conflict resolutions - is it possible to put them into GNUe ?. (See also previous discussions in )

Continuing , Derek Neighbors (dneighbo) reported that master-detail reports doesnt choke now but not sure how to use it for out put. He asked can i put section tag inside the record?. Jason Cater (jcater) confirmed this. Derek pasted some sample XML. Jason confirmed that's how detail datasources work in reports. Derek said he had to put the name of the field in the master table in the XML, but if i leave that i bitches thats not a valid field - if i change it a valid field in the detail table instead it barfs. He was not sure if this could be something in my syntax - or it could be in the code.

Some days later, Derek Neighbors (dneighbo) said i about have my reports ready for demo, although it was not really production quality as of time of writing. He had found that php exec/system calls are pretty freaking weak wrt: debugging - but now i at least have a SIMPLE script where if you hand it WO/SR number it prints my form :) He asked Jason Cater were you able to fix master/detail in reports - it would be more impressive for demo tomorrow but not mandatory :) Jason said he would try to look at tonight - I'm sure it's not a big fix - as it was working. Derek said one of the problems he had had was using the file extension for Forms rather than Reports out of habit and php had not given him a sensible error message.

Later, Derek reported hey i have dcl using gnue reports as of um - 30 seconds ago. He had been able to rather easily hack in to a dcl workorder template to make it call report engine. He said that his employers might be willing to be a DCL/Reports reference site. David McWherter (dtm) suggested push that dcl logo proudly, my friend. Derek said um im pusing it as GNUe DCL :) - which doesnt have a logo.

Derek asked how to do conditional/compound queries in Reports - he needed to do an AND and have the and hard coded :). Later, Jason said you can do: and or not eq ne lt gt le ge like notlike between notbetween and any nested combination thereof - oh, and: add sub mul div - I'm sure we put some more in there - boy, someone should document this stuff <cough>.

The next day, Derek said wish me luck, i go to present gnue dcl in 5 minutes to the 'big boys'. Several people cheered him off. Later, he reported well presentation went really well, but its rather possible we have already lost due to the purchase of support magic. However, on a good note EVERYONE there seemed to like it - and most wanted to switch now - which is highly promising even if we lose.

Jan Ischebeck (siesel) asked what the short name for the "object server" in neilt's drawing was. Andrew Mitchell (ajmitch) referred to gnue/docbook/Proposals/geasarch/neilt-arch-explanation.txt, and suggested GNUe Object Access Translator (GOAT)?. He noted the documentation said This is the main part of the Application Server. GOAT uses GEDI and GEMA to fulfill requests directed at business objects, after it has checked the validity of the request against GEOR.

Jan noted that neilt want's a "object server" who has MVC (modell view controller) capabilities. I don't know exactly if this is compatible with standart transaction and locking schemes. (like the ones in an ODBMS) . He thought there is the need to make more agreements about the kind of "application server" we want to implement. Everytime beginning with a new component for my "_featuretest" approach, I'm quite unsure if someone agrees with my thoughts.

He asked whether real "objects" will exists in any stage of the appserver or does GOAT just simulates objects out of a combination of data stored in sql DB tables and methods provided by GEMA?. Reinhard Müller (reinhard) explained my plan was to not have python objects - although it seems as it could be easy so it'd be cool to have - but primarly we will have objects that are accessed through the defined api (via geasInstance). Jan asked But if you create geasInstance for each table row. why not directly creates an real python object which inherites geasInstance? Reinhard said if it's easy then we will do it - however other languages are not as flexible as python in creating new classes dynamically - and eventually we will have other language bindings than python for geas. This would mean the geasInstance way will still exist, since the dynamic class will be on client side imho - i.e. the geasInstance will go through the rpc module - and be converted to a e.g. customer object at _client_ side. Jan agreed that this could make the programming of the database adapter easier and it will work with every programming language. But there should be an option to have direct access on the objects. (which is really easy to implement in python), giving an example. Reinhard said that looks good and sane - however do you agree that this would be client-side (RPC wise) ? Jan thought that the trigger code wants to use this feature too, so it would be better to implement it "server-side" - An other possibilty is to write the code once and use it for triggers at the server side and for "getAttribut1" Access at client side. Reinhard thought this was better.

The next day, Reinhard asked Jan whether his latest commits meant that forms work with geasv2?? Jan confimed this but just read only. and without conditions as of time of writing. Jan asked for specifications for reading informations about a table, like supported fields, ... and a specification what kind of arguments are passed to setConditions :) Reinhard suggested define pseudo-objects - so we can use the same interface to get that information as we use to get real data. He agreed about setConditions.

Jan said he had comitted to CVS a gnue/appserver/src/_featuretest file, which was an attempt to implement some ideas from odmg.txt and an book about object servers.. He explained the idea of _featuretest is to have a kind of "object server" which is very very simple, but which has objects to implement the rest of the server funtionality. Because this objects are objects of the objects server they can be updated and reloaded on a running system, and the most important: they can be stored and loaded from a database. I.e. you can store session states, class definitions, normal objects with the same code. Jens Müller (ICJ) said I understand the trigger stuff better now. Reinhard Müller (reinhard) suggested discussing it further the next day.

Derek Neighbors (derek) asked for comments on his idea in about doing a basic Application Server first, with full object support later. Andrew Mitchell (ajmitch) was worried that this would then require another revamp to support objects?. Derek said his concern was the time it might take to agree the object standards to be used in getting a full object-based Application Server up and running. Daniel Baumann (chillywilly) said that, if everyone was happy to use the ODMG standards, there are no debates, imho.

Earlier, Reinhard Müller (reinhard) said i still believe that is like saying let's drop apples and only do fruit - dbabstraction + triggers == basic object function IMHO. Derek said that all he was suggesting for a first pass was no need for a GNUe Class Definition (gcd) file. Reinhard asked where will we define what methods exist and where they are stored in that case?

Later, Jan Ischebeck (siesel) suggested I think we should do it the fast way. There is the need for a basic appserver in the next two months. But for the appserver which will be implemented in one year, i would like a more general approach.. Daniel asked and the long-term one would be based on what?.

The next day, Jan asked do you think that appserver v.0.1 allready needs Object/ClassDefinitions? Or should it just pass arguments to and from the common dbabstraction layer?. Reinhard said we have to do a roadmap, suggesting:

This would make 0.1 as the first version that really makes sense to use - with only basic fields (string, number, boolean, datetime) - then in 0.2 0.3 0.4 etc we add features like reference fields, list fields, indirect fields, calculated fields, triggers. Jan suggested doing reference fields = 0.3 for example. Reinhard said i'm not quite sure about when to implement namespaces and especially on how to implement them, explaining namespaces == modules. He was worried if we can stay compatible if we add namespaces later - so we might have to do namespaces in first "official" version.

Earlier, Jan asked should appserver access more than one database? Reinhard thought this would be a fairly late addition to functionality, but 1.0 should be able to.

The next day, Reinhard told Jan btw saw your ROADMAP and agree mostly, but issues such as introspection or support of more than one database or security concept. Jan said he thought introspection should be implemented when the GClassDef/GObjDef Stubs are added. that means before v 0.0.2. Reinhard agreed - if we decide to put class definitions in the database then introspection will be easy anyway. Jan said I think we have to put very very basic introspection support into v 0.0.1 just to make the dbadapter work.

Jan also suggested adding 0.0.4 has very basic security support (=login and password check) to the roadmap. Reinhard said that it was probably best to have a firm roadmap to 0.1.0, then add - Later (unsorted). Jan said he saw 0.5 as an important milestone as this is the point where appserver supports transactions. i.e. appserver is getting usable in large enviroments, like 0.1 means usable for a small application. Reinhard wasn't sure whether it made sense to plan that far ahead - what we could do is just list the post-0.1 features unsorted and decide about the order to implement them later - after talking to jamest and jcater about appserver and what they want to see - and maybe after getting experiences with 0.1 and seeing what is missing most urgently, adding Planung ist die Ersetzung des Zufalls durch Irrtum. Planning is the replacement of the coincidence by mistake. Jan accepted this, but said I would like to have a "Version 1.0 must have" in the roadmap. just to see what feature is really really needed for that important milestone.

Reinhard asked did i understand correctly that we need xmlrpc to connect forms with appserver? Andrew Mitchell (ajmitch) said it shoudl be able to run without xmlrpc for single-server installs - well, when forms & appserver are on same box. Jan said as I understand it : appserver needs GNURPC to run. but there is only XMLRPC working now. Other possible transports included SOAP, Corba, piro... Reinhard confimed that GEAS would use GNUe Common (and hence GNU-RPC) from the start for data access.

Gontran Zepeda reported his progress (as previously discussed in ) on the Not So Tiny Text Interface (nstti), a set of wrapper classes to the curses library module, concluding that nstti base classes aren't feature complete ;) as of time of writing, but he would simply add and enhance widgetry as needed. He asked for examples of the many excellent curses applications currently widespread to garner ideas on how to implement some of the more non-obvious widgets in curses. He was hoping that nstti may work on win32 via cygwin shell, probably no mouse though, although this had not been tested yet. He posted a hyperlink to a sample screenshot.

John Lenton noted some well-formedness problems with The gnue-forms.dtd, giving examples and corrections. Later, he noted that his proposed correction to the "boolean" entity was still wrong, and asked Maybe somebody with more XML than I can tell me if (why) it should be something other than <!ENTITY % boolean CDATA #IMPLIED>.

Further to , John Lenton reported that the first version of the entity relationship diagram (ERD) for PAPO, an Argentinian-based ERP project using the GNUe Tools, had been posted on the web, and he asked for any comments.

Arturas Kruikovas said he would not be around for a while because of exams, but reported progress to date on i18n support, as previously discussed in and other previous threads. As of time of writing, he had almost finished i18n data, that depends on client (you can have menus and labels and etc. in your native language). Data, that is taken from form (.gfd) itself, is not yet i18n, that is considered to be the next major step..

It was asked whether GNUe could run as a stand-alone application, using DBase files on a shared folder as a back-end database. Derek Neighbors (dneighbo) said you would just need to make a driver for dbasefiles - i think someone was toying with using gadfly (or whatever zope's local db is).

Gilbert Nunya (Gilbertyoda) asked what language GNUe was written in, and got very enthusiastic when Reinhard Müller (reinhard) confirmed it was python - 99.5 % of our code is python - the rest of 0.5 % is shell script ;) Peter Sullivan (psu) explained the original App Server was in C - the current re-write is in python. He explained a) people write appservers in java, which is if anything slower - b) if we get serious perf issues, we can optimise the key parts of code in C & link them in - as python is a good C wrapper. Reinhard said well if you hear psu talk you wouldn't think that he hasn't written a single line of code yet, would you? ;), adding what scares me is that you can talk like a professional senior programmer :) Peter said he reinhard: I just repeat what Derek says - works for me ;-).

Peter said that GNUe was based on Python 2 - Main problem is that most of the standard distros(esp Debian) are still stuck on 1.5.3. He personally would probably end up learning python when it becomes no longer necessary - i.e. by the time we have the Designer working with AppServer to allow you to graphically create triggers w/o knowing any python at all.

Gilbert asked how he could contribute - I don't wanna watch you guys have all the python fun!. Reinhard suggested downloading CVS and seeing what area looked interesting - gnue is a very big project and you have to pick your favourite part out of it. Gilbert asked do I need to know XML?. Reinhard said i don't know XML and i still pretend to work for this project. Peter said that the transistion from HTML to XML was fairly painless - after all, *I* understand XML, at least enuf to write it. Gilbert wasn't convinced - XML is one ugly mother. Peter said Eventually, most of the XML will be auto generated - already we have Designer set up to produce the XML for Forms definitions - and intend to use it for Report Definitions, App Server definitions, Navigator menu definitions... oh, and world peace and harmony between the nations.

Gilbert asked about postgresql. Reinhard said it's our prefered db backend. Peter said we work with shed loads of d/bs free and non-free, noting SAP-DB is now GPL.

Gilbert asked about implementation timescales. Reinhard said as most free software projects we have no fixed and planned release dates - it will be sooner if we have more people that help :) Gilbert asked how much python do I need to know to help? Derek Neighbors (dneighbo) said none, since, as Reinhard said you can also help by finding bugs, testing, making proposals on how to improve things, writing documentation.... There were lots of different skill sets already in the project - we have hackers with zero business knowledge as well as non-programmer accountants but everybody so far has been able to contribut something that wasn't there before.

Continuing , Marcos Dione (StyXman) asked can I enlarge or shrink the # of rows, from the form? Derek Neighbors (dneighbo) said this was not possible at runtime, but you can make it say 10 or 20 or any number at design time. John Lenton (Chipaca) asked is there a design decision behind that, or is it just "not at this time"? Derek said there are plans to use real grids which would give you some resizing capabilities - but really i dont see much value in being able to 'add' more rows unless resizing a form.

He added remember gnue is designed to be highly portable to many platforms and be extremely quick to write applications - which means generally you will lose some of the 'pretty' fluff microsoft has taught you to love. John asked I was wondering if there was a way to get ctrees, but we thought nah they mustn't have done that because of the html, but then I saw the dhtml (your dcl_dict i think it was), and I said hey! that's how you do it with html! so where are the ctrees? Derek said this was the same principle - how would you do a tree on a palm pilot, or curses or with a telephone? He added we are not opposed to such items, but because they cause other issues they are not super high on the todo list - but we would be willing to do or support as much as possible others efforts to do such things. John felt the curses point is rather moot seing as designer picks up its widget lists from wxwindows. Derek said we made a decision that for now designer would be dependent on wx - but applications should not - as we dont see a huge value in having a full fledge IDE for palm or the telephone :) - we do see value in having applications run there :)

John asked ok, but if we made the decision that a palm device, or curses, or telephone were out of the question for other reasons, we could hack in ctrees, right? Derek agreed - we plan on putting layers in - so that we can have 'non standard' items - like a cTree say - and 'official applications' would not use it. John said not unless we came up with a curses way of looking at ctrees :). Derek continued we would disclaim that we cant guarantee that these 'extensions' will be up to date with newest version etc - but we wouldnt be unfriendly to someone wanting to write an extension which might even get adopted as 'official' if it was useful and supported.

It was asked how complex GNUe Reports could get, and in particular whether sub-reports were possible. Derek Neighbors (dneighbo) said that there were no charts and graphs as of time of writing, and subreports it kind of can do depending on how you define 'sub report'