GNUe Traffic #4 For 24�Nov�2001

GNUe 0.1.0 released this week - this stuff is so great I can't even find words for it

Reinhard M�ller explained his reasoning for changing the syntax for explicit references to:

REFERENCE name: otherclass.otherfield = thisfield;
LIST name: otherclass.otherfield = thisfield;

Neil Tiffin said he thought the colon and semi-colon made it look like "programmer lingo" , and suggested WHERE instead. Reinhard agreed about the colon, but said the semi-colon was there to help the parser. Neil said that WHERE could be aliased for non-English speakers. Reinhard was not sure this was a good idea - "and I say that as a non-native English speaker" . Neil said it was "Probably not a big deal except that we should always evaluate ways to show the project is multi-national." Derek Neighbors said other "programming languages" had normally just used English. Reinhard said that some German-language versions of Excel and Word had used German for Visual Basic keywords. "So instead of IF..THEN you wrote WENN..DANN, and it looked highly ridiculous to a programmer."

Reprising his theme from Issue�#2, Section�#21� (6�Nov�2001:�Website redesign and mailing lists) , Reinhard M�ller (reinhard) said "We really need a good and simple webpage which basically says "GNUe is not yet there, we have only parts of it"" Derek Neighbors (dneighbo) agreed - "I started to look at phpnuke and I think we can make it work" . Reinhard suggested "a rather static page for an overview of the project" . Derek said "that's what gnu.org is for - its just not been maintained" . The main reason for moving to a dynamic front page had been to "make it easier to let OTHERS maintain" , as getting volunteers set up with write-access to gnu.org had taken time, but he admitted "the current way isnt working famously either :)" Later, he said "static or dynamic I think is not the point - we need someone to MAINTAIN the website - that is the REAL problem :) IMHO as we had SAME issues when we only had gnu.org site - it was grossly outdated" .

Jason Cater (jcater) asked people to test the pre-release of the "Windows installer binary" . Reinhard M�ller (reinhard) asked what the dependencies were. Jason said just Windows(!) - plus "a database backend :)" - although in fact the "Hello World" form did not even need that. Reinhard was seriously impressed, and asked whether the installer could be used for GNUe Application Server as well. Jason said "it's Inno setup - a generic free installer" . Running it, Reinhard said "um at first sight i would say "hey jcater has reimplemented delphi" :) [...] this stuff is so great I can't even find words for it" .

Testing, Reinhard pointed out "I can't close a property editor window once it popped up" . Later, Derek Neighbors (dneighbo) was getting "serious errors when trying to edit a form in designer" . However, he tested GNUe Forms against " mysql, pgsql, msaccess97 - now for looking at db2 :)" . He thought this was one of the easiest installs he had ever seen. Jason said "we are by far a 0.1.0 level quality of work - at least forms client is :) - designer needs more polishing - but, eh, we're getting there" .

Two days later, Jason asked "derek: can you do a sample intro form??" . Derek suggested "a tabbed form - where every tab is a sample" . Jason pointed out that you could set tabs up in Designer, but you could only see one tab at a time "i.e., each tab is a separate "grid"" . Later, Dmitry Sorokin (ra3vat) reported that " non ascii forms does not work" .

Another two days on, Jason announced "New Windows 9x/2000 prereleases (0.1.0-c)" and asked people to test them. There were some minor problems with pink icons and tabbed forms, but these could be resolved.

Further to Issue�#3, Section�#12� (13�Nov�2001:�Documentation for release 0.1.0) , Daniel Baumann questioned the use of LyX for GNUe Documentation. He realised that people were having problems with installing docbook, but said "I can build html versions of stuff on my box if this is what we have to do." He added "I really shouldn't have to be harping on this issue for a GNU project, but some ppl like to take convience over freedom and this should not be tolerated. I mean I would love to read the forms technical reference, but there's no way in hell I am going to install lyX unless I can have a fully free version with the toolkit of my choice (which is supposed to happen eventually)." Michael Brown suggested "why not just compile LyX with the QT2 toolkit? According to http://www.devel.lyx.org/guii.php3 , this is pretty close to being complete." Daniel said he had tried the QT port before, and was not impressed. Jason Cater said "The upcoming release was originally planned for this past weekend. James and I decided to postpone the release by at least a week to generate useful (both technical and non-technical) documentation -- and that is just what we have been doing! Our sole intention was to generate as much useful documentation as quickly and painlessly as possible." They had used LyX because they had had problems trying to get docbook to install. Neil Tiffin said "I would much rather have docs in any format than no docs at all." Chad Walstrom pointed out that "the lyx file format is not a proprietary format. It's simply "yet another LaTeX style sheet"."

Daniel reiterated his position, and said " I feel that this issue needs to be ironed out and I apologize for the prior language, but I am very frustrated and I feel alienated" . Derek Neighbors said "I dont see how we are forcing ANYONE to INSTALL anything. LyX is simply structured LaTeX. Anyone that has a file editor can look at and edit the source files w/o installing any additional software. They can even make the conversions using LaTeX." He continued, "I think we have always had the stance of 'docbook' is the 'preferred' format of documentation, however we will take documentation in ANY format. I know I have personally accepted text files, texinfo and word documents and converted them to docbook. This motto is because we know its hard to find documentors so we wont term them away REGARDLESS of their tool." Daniel proposed "that we use text for now and I will volunteer to do docbook or we just switch to something that works better on all systems like say textinfo. What do you guys think?"

There were also full and frank discussions of this issue IRC on 14th, 15th and 16th November.

Michael Brown (mcb30) asked " what's the differnce between running with and without GEAS?" Reinhard M�ller said "the most important difference is - running without geas works - - running with geas doesn't" . He explained that "business objects are like " intelligent" database tables - not only data but also methods" . In a working GEAS set-up, GNUe Forms/Reports would "access the business objects instead of the db" . The main problem with GEAS as of the time of writing was speed.

Later, Neil Tiffin (neilt) confirmed that GEAS only worked with either C methods or Python methods, but not both. To do this, it would need code to catalogue both the C and Python methods, determine "which style of methods to use" and handle duplicated names. Michael asked "With the python methods, is it permitted to modify the python code while GEAS is running or not?" Neil said "it loads all methods into python at startup" , so changes would have no effect. Derek Neighbors (dneighbo) explained some of the initial thinking behind this, and said it might be better if "you place the new code out there and its not loaded until you specifically tell it to" . This could even be linked to a cron job for periodic updates. Later on, he confirmed that he did not favour automatically loading new methods, as "some transactions could be mid 'flow'" at the time the code changed.

Later, Michael reported "I seem to have found a problem with the python method dispatch" . Reinhard confimed "every module should have its own namespace" and said "this is scary - you seem to understand that code better after 6 hours as i do after 6 months :)" He said that the parser library "is being rewritten at the very moment" , and invited Michael to submit any "wishes" for it. He also asked for input on coding style issues.

The next day, Michael outlined the changes he had made to the GEAS code to allow it to support both Python and C methods at the same time. He asked "is it acceptable to have no method handling support built in to GEAS" ? Daniel though this should be an error condition - "what good would the server be with 0 methods?" The consenus was that the default would be to compile all types of methods. Later, Daniel said he would like to be able to mix and match methods "but at the object level" - GEAS would search for something that could implement the language, load it into cache if necessary and then load the method. He feared this "might be kinda slow though" .

Three days later, Michael asked "Is it reasonable to assume that all methods for a particular class that are of a particular type (e.g. glibmodule) will be implemented within the same file?" Reinhard M�ller said "not at all imho" - they might even be from different applications. Michael said he was "thinking about dynamic loading and how to determine which methods need to be reloaded when I notice a file has been modified" - he could scan all methods, or keep a cache. Reinhard said "can't you query what methods are contained in a file?" Michael said this wouldn't cope with methods being removed. He described how a cache would work. Reinhard suggested "glib's GList implementation" for the cache lists - he was not keen on GHash. Michael was worried about speed and scalability for long lists - Reinhard thought "the time needed to reload a single code file from the disk would be more significant," but left it up to Michael.

Following on from Issue�#3, Section�#5� (9�Nov�2001:�HTML client for GNUe Forms) , Michael Maluck (madlocke) said one of his biggest problems had been "how the widgets are created" . Andrew Mitchell (ajmitch) offered the use of his webware set-up for testing. Later, Derek Neighbors asked Michael to send his code to James Thompson as a tarball, to avoid having to keep uploading it. He asked "how are you doing record traversal?" Michael replied " I am just exchanging data between html and the gnuef widgets... so no big change in the handling..." .

The next day, Dmitry Sorokin (ra3vat) confirmed that the code was not intended to currently work with GNUe Application Server - "it's just form's ui driver" . Andrew Mitchell (ajmitch) reported it needed Python 2.0. Dmitry finally reported getting the code working - "it is great" .

Another day on, Andrew and Charles Rouzer (Mr_You) were still having problems getting Webware to work. Dmitry said he had temporarily uploaded "the current uiwebware driver" for Michael, who would be back on Monday.

The next day, Michael confirmed that Andrew would need to upgrade to Python 2 to get the Webware code to work. Charles said "you'll need to have a curses library" , as GNUe Forms needs it to install. Jason Cater (jcater) confirmed that GNUe Forms needs at least one User Interface to install - Charles said it would have to be curses, as "this is a remote server" . Jason explained "you can comment out the checks in gnuef/setup.py for now" to force GNUe Forms to load without any User Interface. Charles was still having problems, however.

Relieving the pressure, Jason clarified that "0.1.0 will be released before we add the webware driver, just so nothing breaks" , but the driver would be added immediately afterwards.

Reinhard M�ller (reinhard) proposed a new poll for the web site front page asking how people had found out about GNUe - he suggested:

gnu homepage
freedevelopers
kernel cousins
bathroom wall
"the voices" told me

Michael Brown (mcb30) said "I think I probably found it via Freshmeat" - he had been impressed by "the level of attention to detail in the docs" .

Returning to his theme in Issue�#3, Section�#4� (8�Nov�2001:�GNUe Form triggers - XML?) , Daniel Baumann (chillywilly) asked about using GObject. This would create a dependancy on glib 2.0, but "we need a much more OO design of things" . It would give GNUe inheritance and thread safety, and potentially multi-threading. Reinhard M�ller (reinhard) asked about portability, and said "lately i see such a ton of projects being killed by their dependencies" . Daniel pointed out that GNUe was already dependant on an earlier version of glib. He would check "exactly what systems it will compile on and work" . Whilst end users wouldn't notice much difference, it would help developers - "I am not doing my own OO glue crap in C and yes I like programming with objects" .

The next day, Daniel asked "what would you think of business objects being parsed into GObjects?" This would allow objects to be updated "on the fly" , giving real inheritance. Reinhard was worried that GObject "adds a lot of overhead" , but would be interested to see Daniel's code.

Alan Clifford asked if it was "a goal of GNU Enterprise" to not require any irreversible implementation time decisions. Neil Tiffin said the aim was to provide as much flexibility as possible, but "I doubt that we will be writing large sections of code just to eliminate implementation time decisions at this point. Our goal is a fast, scaleable, object oriented, distributed server."

Michael Brown confirmed "I have GEAS working with a mixture of python and glibmodule methods loaded simultaneously." He asked how long FSF copyright assignment would take. Reinhard M�ller said "it usualy takes more than a week altogether" , but he would ask Derek Neighbors to expediate. He would also like to list Michael's company as a project sponser. Derek Neighbors asked Michael to e-mail the patches - "Generally we dont give CVS access immediately even after assignment is done." Michael said he thought "this sort of thing creates a huge barrier to attracting new developers" . Derek also said copyright assignment was normally done by snail mail, but "If we wanted to put a huge rush and you have a fax it could be arranged" . Michael supplied his fax number.

Neil Tiffin asked Reinhard M�ller to "look at modifying configure" to allow both python and C method support at the same time. Reinhard agreed - the "default is to have both. It is possible to configure with no method support at all, but then a warning is issued at the end of configuration" .

Michael Brown suggested that there should be "two main types of dynamic method loading that we would like to support in GEAS" :

Instead of each method provider (python, glibmodule) checking all of the methods to see which ones it recognises, Michael "would like to restructure this so that methods.c does the "scan for all methods" part and then calls each provider in turn to say "can you implement this method?"." This would also reduce spurious error messages. He added "It will also make it easier to add other method types in future" .

Neil Tiffin said the "code will need to support people that only configure one type" of methods. Michael accepted this, but added "the configure script MUST throw an error if an attempt is made to configure with support for no method types," as he was no longer checking for this.

Later, Daniel Baumann explained how the support for multiple types of methods at the same time would work. "Basically a method call comes in you search the cache for the method and the apporpriate method provider and load the language plugin...if it is not there you interrogate the plugins and update the cache." He later added "this would be a nice time to switch to using GObject as the real solution here would be a lot nicer using inheritance" . He concluded by discussing the issue of protection - " a bad method should not bring down the whole server." Neil Tiffin agreed, and suggested several other issues on GEAS that needed resolving, but added "These goals do not have to be achieved in the same code rewrite."

In a seperate part of the discussion, Neil said that the priority now that both python and C methods were supported was probably to "rewrite query IDL, it does not meet the needs of forms and is too slow." Reinhard agreed, but said "I would think that we should wait for the forms team to define their needs, before starting this." But Michael said he would like to do dynamic method loading first, as it would be a real boon to him in testing new objects.

Derek Neighbours (dneighbo) said " I wanted to make the db sample we distribute have a SQL script for each DB we support and thought it would be easier to use the ddl tool than to hand write it :) and thought hmmm probably shoudl include this in gnue :) as i want to do the 'inserts this way too'" . Michael Dean (mdean) agreed. Derek said "so now you do a db create script in xml and run a python program and it spits out db native script" . James Thompson (jamest) was very, very enthusiastic about this. Derek said they already had style sheets for many databases - "and creating a new one is as simple as copying exisitng style sheet" . James asked "why not make a sql92 compliant one" ? Both Derek and Michael pointed out that there was no such thing as a fully compliant database, but Derek said "I see your point, might make one that is sql92 compliant so in theory a bit of minor hacking might make it usable on your db" .

Following a discussion about getting GNUe into RedHat distributions, James Thompson said "I think we should wait for 0.3.0 (ui rewrite) for that personally as it'd have more wow factor" . Jason explained that the User Interface rewrite would allow GNUe to "address the shortcommings in the current UI" . James said he wanted to "add dynamic positioning, menus, etc, etc [...] add curses, web, wxPython, gtk, qt ui drivers" and thought "layout management would be nice" . Daniel Baumann (chillywilly) said "software is always a work in progress with various states of usability and functionality" . Derek Neighbours (dneighbo) said he "often wonders though why spend time supporting ui's we already support or platforms we support i.e. I think its a good idea to make it easier to do so, but not necessary to do it, let someone come along and do it" . James said it was a good way of stressing the design and it "weeds out lots of bugs" . Derek agreed, but stressed the need for "distributable applications :(" . GNUe should now be "advancing other tools - integrator, reports, geas etc" .

Daniel Baumann (chillywilly) asked "do you guys think that when GEAS is more usable that you could build a SF like system using web forms and GEAS?" . Michael Dean (mdean) said that was what DCL was - "that's the plan - to make it a GNUe app" . However, "I have too many commitments to the PHP version to start on the GNUe stuff" yet.

Reinhard said "writing a python test that works with python 1.5 through 2.2 and with different distros seems to be a hard task..." He said "Once I have time I will look at other project's tests - like the one from orbit-python seems to be quite good" . Derek Neighbors (derek) said " we lept to 2.x dependency in forms stuff - we probably should in geas as well" . James Thompson (jamest) agreed.

Derek Neighbors (dneighbo) said "the two auxillary things i want to see started are - workflow, document managment" . These would link to virtually every other part of GNUe. For workflow notifications, " you could 'bolt' those into the form via triggers but it wouldnt be the 'long' term solution" . Nick Rusnov (nickr) asked "What sort of work should I do on the docustore if I pursue it?" Derek said the key issue was ensuring any work done was "completely GPL" . Nick said "I can work from the work I've done as long as the implimentation is independent" . In terms of the specification, Derek said it "should be tightly integrated into geas/forms/reports (which should be a given IF its using common properly)" . Nick said he didn't want to tie the design a particular language - "Its an interface spec so the language of the modules is irrelement" . Derek agreed, and said that if the server used GNUe Common, people could "any language and treat like a black box " . However, he though Nick would find it easier to use Python than C, as that was what GNUe Common used.

Nick said "My main design issue now, though, is authentication and security" . Derek said that document management could be useful "even OUTSIDE security" . Security needed to be a shared issue for the whole of GNUe - "security and workflow are like the two things most everything will need to use" . However, "right now there is ZERO ZIP NIL document management stuff (that i have seen) for linux or free software in general" . So this would be "a HUGE win even if basic or no security and basic or no workflow attached to it" . Even a basic "yes you can log in or no you cant" level of security would be a start, and this could then be developed further.

James Thompson (jamest) said the 0.1.0 release would be "tonight or we die trying - all remaining bugs are left as is unless they prevent install" He said Jason Cater (jcater) "has a release blurb for the site done" . The release had involved much more work than expected - Jason said "designer basically underwent a 1/3 rewrite in the last 3 days :)" . James said they had "added setup.exe support to both products" . There were currently no RedHat rpms, but Jason said "we perfected Win install :)" . Andrew Mitchell (ajmitch) felt "rpms aren't essential, debs are" .

The next day, very early in the morning, James Thompson (jamest) said "it's official 0.1.0 is out" . Jason Cater (jcater) said "let the breakage begin" . He added "this is a big milestone for us - this release was 4 months in the making :)" Charles Rouzer (Mr_You) got the first bug report in - " File->Open in Designer" but found a work-around. James said "our first bug submission was before we had links posted - that's scarry" . After catching some sleep, James reported that there had been "209 downloads - no bug reports - hmmm, they must not be able to install it - 78 win32 downloads - ~48000 hits on the site" . Later, Derek updated that "you realize that the freshmeat release, plus kernel cousin, plus eltoday story has at over 75,000 hits today :)" .

Reinhard M�ller said "Currently, whitespace (as well as a comment) is ignored between two tokens, and is permitted in every possible token gap." He wanted to know if this was desirable.

Neil Tiffin reported problems with autogen.sh when trying to configure GNUe Application Server. Reinhard M�ller said "I am currently using older versions of automake and libtool" , but would try it with the same versions that Neil was using. Later, he reported that part of the problem was that "Automake 1.5 has better checks than 1.4 :) - I fixed the Makefile.am's." . The rest of the problem "is probably that you have updated libtool while still having old ltconfig file hanging around here" .

Michael Brown (mcb30) said he had " done some thinking about methods, geas and code-sharing" and had documented them at http://www.fensystems.co.uk/geas-ideas.pdf or http://www.fensystems.co.uk/geas-ideas.tex. Later, Derek Neighbors (dneighbo) said the document was good - "as we need specs for geas and how it will work with forms :)" He added "with some polish i think this document could be useful as 'the managers introduction to gnue'" .

Later, Reinhard M�ller said "current state we see geas not providing lookup fields directly" and described his preferred way of acheiving the same effect. This meant that the object reference fields would be "read-write" . Michael asked " how do you use that through a non-OO interface" ? Reinhard said "we can of course have 2 different interfaces - one providing a relational view and the other the oo view - but for the relational view i'm not sure for what we need geas anyway - and why not accessing the db directly for that" . Michael asked whether the data interface in GNUe Forms treated the data as object-oriented or relational, and said "I was thinking of the code that provides the data interface being part of gnue-common rather than just GEAS" . Reading further in the document, Reinhard said " i definitively like the idea of a single method language that is translated into whatever the method executer understands [...] as long as i don't have to implement that :)"

He added "2 tier and n tier were regarded as two complete different worlds once - and the distance between them seems to fade away" . He was worried that if 2-tier became too similar to n-tier it would lose its simplicity ; if n-tier became too similar to 2-tier it would lose its power and scalability. Michael said "I don't think that should happen, but it would be good to share code where possible" . Reinhard said he felt at an emotional level "that geas is in the process of loosing importance continously" . James Thompson (jamest) said "not at all - geas is the cornerstone of the n-tier gnue - we just want to gut it lots of it to put in a common lib" . He had had similar issues with GNUe Forms/Designer, but "I took secret pleasure in watching gnuef distro size shrink [...] while some people boast 750,000 lines of code here I am hoping to make our code base smaller" . Jason Cater (jcater) said "I've always heard that a sign that a product is maturing is that it's code base starts shrinking instead of growing - of course, there's no way forms is mature :)" Reinhard mentioned the old Chinese proverb - "something is perfect not when there's nothing more to add but when there's nothing more to take away."

Derek said, although he agreed that more GEAS code should go into GNUe-Common, then " geas almost becomes a python application" . He clarified that although a method in n-tier was similar to a stored database procedure in 2-tier, this wasn't how it should be implemented - this "defeats MANY of the goals of geas" . He continued "the MORE i think about things i think we shoudl be using xml" for GNUe class definitions, as it would make them human readable and easy to convert to other formats - "its as easy as writing a stylesheet" . He pointed out that the Data Definition Language was already in XML for GEAS, and the intention was to move this into GNUe-Common as well.

Reinhard later said ".gcd files are not xml [...] xml will be the interface between 2 systems but not between a system and a user" . Derek explained that the XML would be "the single source code that gets turned into db triggers/stored procs" . This meant "you end up with a nice clean .xsl file for each db implementation and it serves better as an INDEPENDENT tool - part of the goal of GNUe is all tools work together or separately" XML of itself would probably not create any extra dependancies, as it was needed for other parts of GNUe, notably Reporter.

Derek clarified what he personally needed from GEAS - "middleware that operates independently of the client or the datastorage - specifically, it allows for remote communications to both the client and the datastorage. It should allow for remote method invocation." The key functionality would be:

He explained "part of b is getting rid of a vendor dependency (the norm for db triggers/procs) - the other part is making it so integrator, reports, etc can all use the same rules" . Michael felt his ideas were very similar:

Aggregation of database backends. GEAS would provide a single "virtual database" in which the actual data might be spread over several different database backends (PostgreSQL, CVS, etc.).
Support for methods (i.e. business rules)

Derek said "my big hang up was making methods storedprocs/triggers in the db" - this would make it vendor-specific, but might give big performance gains. Part of the GNUe philosphy is that you should not have to learn another computer languague to make it fit your needs.

Derek Neighbors (dneighbo) announced "dotgnu, gnue, gnucomm, dcl, phpgroupware" were looking to have a structured private IRC session to discuss joint issues. Charles Rouzer (Mr_You) suggested "why not open moderated IRC?" Charles and Nick Rusnov (nickr) explained how this worked. Derek said the "tenative schedule is for 9pm EST monday" .

�
Kernel Traffic Latest�\|�Archives�\|�People�\|�Topics	Wine Latest�\|�Archives�\|�People�\|�Topics	GNUe Latest�\|�Archives�\|�People�\|�Topics
Czech

1.	14�Nov�2001�-�17�Nov�2001	(8 posts)	Non-English programming keywords
2.	15�Nov�2001		GNUe Web Site
3.	15�Nov�2001�-�17�Nov�2001		Testing Windows Installer for GNue Forms/Designer
4.	14�Nov�2001�-�17�Nov�2001	(10 posts)	Using non-free tools for GNUe Documentation
5.	16�Nov�2001�-�19�Nov�2001		Working on GNUe Application Server (GEAS)
6.	16�Nov�2001�-�19�Nov�2001		Madlocke's HTML client and Webware
7.	16�Nov�2001		Finding out about GNUe
8.	16�Nov�2001�-�17�Nov�2001		GObjects and glib dependencies
9.	16�Nov�2001�-�17�Nov�2001	(2 posts)	Irreversible implementation time decisions
10.	16�Nov�2001�-�17�Nov�2001	(6 posts)	FSF copyright assignment and CVS access
11.	17�Nov�2001�-�18�Nov�2001	(3 posts)	Configuring GNUe Application Server for multiple methods
12.	17�Nov�2001�-�20�Nov�2001	(18 posts)	Dynamic method loading in GNUe Application Server
13.	19�Nov�2001		Data Definition Languague (ddl) for GNUe
14.	19�Nov�2001		Plans for version 0.3.0
15.	19�Nov�2001		DCL for Project Management using GNUe
16.	20�Nov�2001		Testing for Python
17.	20�Nov�2001		GNUe Workflow and Document Management
18.	20�Nov�2001�-�21�Nov�2001		GNUe Forms and Designer 0.1.0
19.	20�Nov�2001	(1 post)	Whitespace in .gcd files
20.	20�Nov�2001�-�21�Nov�2001	(4 posts)	Problems configuring GNUe Application Server
21.	21�Nov�2001		GNUe Application Server (GEAS) Strategy
22.	21�Nov�2001		Multi-project IRC planning session

GNUe Traffic #4 For 24�Nov�2001

By Peter Sullivan