GNUe Traffic #19 For 9�Mar�2002

It also covers the #gnuenterprise IRC channel. A great deal of development discussion for this project goes on in IRC. You can find #gnuenterprise on irc.openprojects.net:6667, or you can review the logs at http://www.gnuenterprise.org/irc-logs/ (http://www.gnuenterprise.org/irc-logs/) .

Derek Neighbors (dneighbo) suggested starting with the lessons learned from the existing GNUe Application Server (GEAS), then defining the goals and direction of a new GEAS. He said GEAS had " evolved w/o direction - meaning it was something treshna designed for specific own needs without a direct definition of what it was to be " . James Thompson (jamest) said GEAS had lacked "forms support, security, performance, stability" . This last point was much better than it had been, and was now mainly due to problems in his area anyway. Reinhard M�ller (reinhard) said when GEAS had been originally written, it lacked "coordination, goal, interest from other team members" (including himself). Derek agreed, but said that this had been partly recognised, and that "the gnue version of geas" was significantly different to the one Treshna wrote for themselves.

Reinhard defined the overall goal of GEAS - "to pull the application logic " (or 'business rules' out of both the Forms and the database backend. James noted that " triggers and the like wouldn't be removed from forms - but in an OO setting they wouldn't be used" . Jan Ischebeck (Jan) agreed " 2- tier is also important" . Derek confirmed "forms in 2 tier mode is kind of necessary to hit our larger goal" , but he and Reinhard wanted to focus on GEAS for the current discussion.

Derek and Reinhard suggested some other goals for GEAS. Derek said that abstraction/independance of database, RPC and language were important - as otherwise "i can use jboss right now today " . Reinhard said he personally didn't care much about these issues, except database independance. Derek said RPC abstraction was important to keep up to date - "CORBA is dead - every body right now is using XML-RPC - but what will it be next month? SOAP??? M$ FOO TRANSPORT?" . Reinhard suggested GNUe should seriously consider just using jboss instead of writing their own Application Server if this was all they were hoping to gain. Derek said the main issues he had with using jboss were " a. its not a gnu project (one goal of GNU is to have a full suite of GNU apps) - b. its java (as are mostly ALL of the free app servers) and the thought of method code in java hurts me" .

Jan re-iterated Reinhard's point of being able "to define business rules, methods and data without having to be a software expert" . Derek agreed, but didn't want to " get into own defined macro language syntax" . He re-pasted the list of goals, which were now up to 5. Reinhard added a few more, and said he still didn't agree with Derek's points about RPC and language independance. Derek said security and stablity were important, but so was usability. He said "you need not be a hacker to maintain or use the softwaer - BUT i dont expect home users to be able to do so - more a business analyst type person" . Reinhard said "i don't think it's maintainable to have 20 dbdrivers for 13 db backends" . James said "i think we hit a good mix in common.... meaning basic support is there and the framework is maintainable" .

Derek asked about " object transparency" - at the moment, the goals did not include this, which was how other free software Application Servers did it. It was noted that 'not Java' sounded a bit negative, so Derek suggested combining this with the licensing issue to say "1. Must be GPL and built with truly free tools." Jan said the "possibility to change buissness objects without breaking old code" was an important goal. Reinhard agreed, and thought that was implied by the goal to "be easy to configure and adaptable without downtime" . James said "i don't think any app server today does that" .

Neil said that, from a business user perspective, he would put different priorities on some of the goals, but felt he should keep out of the discussion at this stage. Reinhard disagreed - "i don't want to end up in writing an appserver that doesn't fit business needs" . Neil said "we need a central repository for defining the business objects (or what ever you want to call them) - So that business functionality can be defined in one place and show up in all the places it needs to in the enterprise" .

Must be GPL and built with truly free tools.
Allow methods (logic) to execute on appserver instead of on client and/or database.
Must be reasonably stable.
Must be reasonably secure.
Must be easily maintained.
Must be usable by business class users (not just programmers).
Must perform reasonably with large quantities of users and/or data.
Must be easy to configure and adaptable without downtime.
Communicate with an number of backend datastorage.
Must run on multiple OSes and Architectures.
Communitate via a multitude of different tranportaion methods.
Methods support a number of different languages. (lesser goal)

Reinhard wanted to see if he could come up with better wording for some of these points, but was happy with the principles. Daniel Baumann (chillywilly) asked " you don't really expect suits to design business objects do you? " . Reinhard said " there is something in between a luser and a hurd hacker ;)" He said "it's about freedom - the user should be free to adapt the software to their needs (freedom 1 IIRC)" .

Jan asked about "an implementation plan?" Reinhard suggested " a. we implement in python for the time being - b. we implement something that fulfills 1-5 and 7 and make the architecture so that the other goals can be reached afterwards - while we simultanously implement the "object designer" and therefore fulfils 6 and 8" . He suggested " merge 6 and 8 into - must be configurable dynamically, centrally, w/o programming skills, without downtime, and in seperate "layers" for various levels of specialization" . James supported the use of python, with bottlenecks recoded in C/C++ if they couldn't be " fixed via code cleanup" or re-design. This was "why i like python approach so much - it's lends itself to readability and it's highly productive" . Daniel said "doesn't make you design better software though ;) - no language can" . Jason Cater (jcater) felt "it can encourage you to, though - just look at perl code - it encourages poor coding, imho" .

James referred to his disussion with Neil about "reusing GTriggerNSObject (or something like that) as part of a core geas object" . Daniel supported this. Reinhard said "please let's not discuss coding details" . James agreed, but said "i guess my point is - I think a huge part of a python based geas resides in common today" . Reinhard said " so the first step was to make common usable for geas" . This would involve:

document interfaces
define stable and unstable parts of the code
define behaviour of the objects

and keeping these up to date. Once this had been done, "we will look at common and see what we can use there and/or what has to be changed " . Then "we will implement a prototype that is possibly limited - but the architecture will be extensible."

Neil asked "are we going to discuss the API's before implementation? or just write code" ? Reinhard said " API definition is the first step of implementation" and asked "who will want to discuss the api? " . More significantly, who would " the GEASv2 team consists of" ? James said he could help out. Reinhard said he would like James' input in " 1. documenting common (interface-like) - 2. keeping the maintainance of common (when we need changes)" . The immediate next steps were:

jamest/jcater: document common
dneighbo: write down the result of this discussion
reinhard: prepare proposal for GEASv2 API against front end
all: comment on this API

Derek said he would enter these as tasks in DCL, and set accounts up for people who didn't already have them. Reinhard said " for the rest of the week i will spend my gnue time on fixing GEASv1 - i guess i will put some 1 or 2 hours work into it to make it at least run all demos without errors" . Neil said "why? - without forms it is useless" . He thought "i would not spend a minute on it " . Daniel wasn't so sure.

Jan asked "how should forms access GEASv2? should form use a dbdriver again, or should there be some extra abstraction level?" Neil said " there needs to be a network abstraction - current geas uses CORBA " . Reinhard said "i guess forms can't use geas via dbdriver because geas isn't a db" . Daniel said "yes, I always thought it was lame that forms forced geas into a [...] relational model" . James said "the datasource system in forms supports twy systems" . Later, Derek (dnSleep) said "would geas not just be a 'driver'" . Jason agreed - "via a common driver I'd think - that way, reports would use the same "driver" - as would integrator, etc" . Daniel asked " does you common db layer make it as a relational source with records sets? " . Jason said "to a certain extent - but that's not set in stone - i.e., at that level, it's more terminology than anything" .

Ke Deng asked "I don't know how do you think of "Analysis Pattern" which might be a useful tool for developing package proposals." He attatched a sample "Analysis Pattern for Inventories" . Dirk Riehle recommended "Martin Fowler's book" on the subject - he had also put some sample 'business patterns' on the web (http://www.riehle.org/practical-matters/patterns/index.html) himself. Neil Tiffin "would very much like to use patterns" but was worried about copyright and licensing issues. Dirk felt that "Open source and the patterns community are pretty much on the same line" , and felt that, because they had to reference prior art, patterns pretty much had to be public domain. He noted " There have been attempts to patent patterns, but non of them was really successful" . Only a particular publication describing a pattern could be copyright, not the ideas behind it.

Ke Deng said "Pattern is a solution for some kind of generic problem .It 's an abstract from concrete context." . A pattern was "a principle or thought we can apply in concrete context rather than a patend.When did we pay money for principle or thought?" . Neil was worried about Dirk's mention of potential patent attempts, but was still keen to use the concept of patters in GNUe, and encouraged people to develop original patterns that GNUe could use without restriction. Derek Neighbors said "I think we all agree patterns are good, we just have to be careful. I do not claim to be an expert and would gladly ask our general counsel (Eben Moglen) his opinion on using copyrighted patterns to design things." . He later said "It the worse case we end up doing own analysis and producing own patterns" .

Dirk said that the whole spirit of patterns "which are canned experience to be used by people." He said "I can understand your fear of a trojan horse pattern or something like it, but for all realistic means you are free to use the Design Patterns, Analysis Patterns etc. of this world. There are at least two reasons: you already use them, knowingly or unknowingly, they are in your code, and even if you weren't using them, the rest of the world does, without fearing any licensing fees etc. because there is no owner." . Daniel agreed, and noted "I am 100% certain that jcater has used some already in his existing code. I am sure we will also use some in GEASv2 code."

Earlier, Neil said "Our UML tool is "dia". Our early discussions were centered around taking UML from dia and somehow generating something that GNUe can use internally. That is still a great project for someone to take on. Any takers?" Daniel said " What is really needed is some good CASE tools period. Like a Free equivalent to Rational Rose or something" - he was aware of several possibilities, but felt " the whole point of UML is to be able to 'communicate' your design to others. This is essential in any software project." Rich Bodo said dia was "real handy" , and gave several (http://argouml.tigris.org/) web (http://www.eclipse.org/) references for information on UML.

Bajusz Tam�s supplied a patch to add " schema introspection" for " Interbase/Firebird database driver" , so "you can use wizards in Designer." James thanked Bajusz, and asked whether it depended on the current CVS code, and how much it had been tested.

Jens M�ller suggested some text for "the base/person package" , to cover the requirement to produce a report "printing all information stored in the system about a specific person" , and other privacy requirements.

Peter Sullivan put his notes " on the kick-off discussions for GNUe Application Server version 2" on the web (http://www.manorcon.demon.co.uk/geasv2.html) . Christopher Brown supported the non-Java aims of GNUe - although there were some free Java Virtual Machines available, "The neat Java stuff tends to need JDK 1.3 or "better," and that is distinctly NONFREE, being heavily dependent on very nonfree Sun code." James Thompson clarified "We are not using java."

Daniel Baumann (chillywilly) asked for Reinhard M�ller's opinion of "the ODL interfaces " he had made notes on. Reinhard (reinhard) said "i found the odmg standard defines so to speak a "way of thinking" rather than a specific syntax" . Daniel felt the same could be said of "OMG CORBA" He felt that OMDG " keep it pretty simple - in fact I think original gcd syntax was a lot hairier" . Reinhard said "however i'm not sure if all of that is applicable to business applications - for example i think the only sort of collection that is useful for business apps is the list" . Daniel wondered why "the dictionary would not be useful? (hashtable) - array certainly would be" but pointed out that it was impossible to " say what data structures are useful without a design of some system/package" .

Stuart Quimby (ToyMan) said " my ecommerce will be in zope - and I'll want to integrate with gnue" Derek Neighbors (derek) said there were many ways of doing this, including:

write zope/python code to do it
write gnue/python code to do it
use integrator

Daniel Baumann (chillywilly) claimed " everything is an object man!" , provoking Jason Cater (jcater) to retort "everything is relational man!" They each tried to disprove each other's thesis by citing examples such as electricity, love, death and meaningful conversation. Daniel said "there's a relationship attribute" in the ODMG Object Model. He said "all objects are relational, but they also have behavior" . James Thompson (jamest) suggested "is that to handle the cases where OO design can't cut it?" , running as he went. Daniel pointed out "you guys use python for cying out loud - from now on you have to code using only lambda ;)" . Jason said "we're all for OO programming, but the data backend doesn't have to be oo - /me thinks of all his business data - millions of stored objects scares the shit out of me" . Daniel said that the objects "can be stored in a RDMS - or a file - or up your nose" .

Jason asked "then why bother with another layer? iow, what is gained?" Daniel said "you only have to think in objects - one domain to worry about - unless you are hacking the backend" . It was another example of abstraction, such as the "rpc absatraction" that Jason was working on, or "the db drivers abstracted" in GNUe Common. He " wonders why people just do not see the power in modularity" . James said "i feel we do that because so many free projects solve a very limited role - you can get a ui tool for mysql or postgresql or oracle - but having one tool that works with them all would IMHO be better" . Derek Neighbors (derek) pointed out that "designer is mostly made up of reused forms code :) - and if you look at the db drivers i think you will see they are as about as modular as it gets - when people can submit patches or new db drivers w/o talking to a SINGLE developer here that says a lot" .

Daniel asked if there was any real need for GNUe Application Server (GEAS) in that case. Jason asked whether Daniel meant that GEAS was an Object Orientated Database implementation - "I've never thought of it that way" . Daniel said GEAS would have an "object data management system - which includes OODBMS, object-rerlational mapping, etc." . Other than tactical coding issues, the main strategic problem with the old GEAS was that there was no Object design in it - "so I figured that using a standard would be quicker" , which was why he had done the notes on OMDG.

On object definitions, Derek asked " would we reuse gcd format and its parser or do a new or modified format - originally i hated the idea but more an more i like idea of XML definition as it would make using designer a SNAP for creating objects and doing objects in UML in dia is only an XSLT style sheet away from pumping to an XML format" . Reinhard M�ller (reinhard) said "i see 3 possibilities for storing object definitions - 1. store it in .gcd and .py - 2. store it in .xml - 3. store it in database" . Derek said "i see database as same as xml, i.e. you could store the data in a database and pull into xml stream on the fly - so that the engine always uses xml" . Reinhard said he would prefer to store object definitions in a database. Derek said "the big thing about making them in db is it becomes a BITCH to edit them w/o a 'tool' and database access" . Reinhard said " what really convinced me for database is it's the only possibility imho to get dynamic updates being accepted in realtime" . Derek felt that using XML could support this too. Reinhard asked "how would geas know that a xml file has changed? or would geas rescan all xml files for every operation?" Derek said users would test changes in a test GEAS first, then migrate them to the live server, either real-time or at a designated time. He felt "you dont want to beable to change objects mid stream on somethings - as it toast transactions in progress" .

Reinhard proposed that GEAS should read object definitions from a database "or from xml files" . He felt "whether it internally translates xml to db or vice versa is imho an implementation detail - and as long as it's transparent to the user it should be up to the one who implements it" . Jason agreed - "it fits in with our model of providing options and not forcing people to do what we think is best" . Derek said "then i guess the next question is defining the implemenation :)" . Reinhard said that the interface needed to be defined first.

Reinhard M�ller (reinhard) was " about to start the translation of your new project homepage to german" , and had found a few problems with the original. Peter Sullivan (psu) said "I will fix the English version asap" . Reinhard asked "who can explain to me what cash management is? (can't translate a word when i don't know its meaning) " , and suggested " i guess its what we call in german "liquidity planning" " . Peter suggested "Cash Management = Treasury Management + Bank Reconcilliation" , but "I would have said that Treasury management is about future (what cash am I likely to get in soon and pay out soon?) but that Bank Recn. is historic (what cheques of mine have cleared? What cheques I have paid in have cleared?)" . Reinhard said the web page list "to me sounds like buzzword bingo" . Peter felt " that's (partly) the point - trying to pick up web searches & get Googled etc." .

Later, Reinhard queried the paragraph that talked about GNUe as a coordinator for other projects in the area. Daniel Baumann (chillywilly) said "we are a 'meta' project - doesn't that fit the bill then?" . Peter said this section was "somewhat aspirational - but also describe things like Derek's work for Toyman - jcater's call centre, jamest's GNUe work and so on - i.e. making it clear that people using the GNUe tools outside of the context of the GNUe ERP packages are also welcome and part of the overall meta-project" .

Further to Issue�#18, Section�#6� (21�Feb�2002:�Debian packages for GNUe) , Derek Neighbors (dneighbo) asked " has anyone tested the latest debians?" . He tried them, and commented "that seems wrong - i didnt get geas so python-orbit should not be dependency as far as i know" . Daniel Baumann (chillywilly) said " it's a dependency for gnurpc isn't it ;)" Derek said "eventually i want us packaged like apache" , with seperate packages depending on the RPC method and/or database backend.

He noted that the current .deb files didn't have a script to quiz the user to set up a connections.conf file for database access, although, for gnue.conf file, " the default values are sufficient i.e. unless you are doing odd things you dont change it anyhow" . There were still "image load issues on designer - but we are getting closer :)" . Daniel also tried out the debian packages, and reported some issues. Jason Cater (jcater) said " the debs are whacked - we really need the source" . Derek said "i think if you do - apt-get source gnue-designer - that you can get the source and fix it :)" .

Yurii Rashkovskii (Yurik) was off to a meeting with his fellow designers at Open E/AS. The goals of E/AS were generally "quite similar" to GNUe, but their approach was "strong object "delegation" (prototype-based) structure" . He said "our objects differs from classic, they're like in SUN Self (generally) [...] there is no "classes", only objects that have another objects as so called "prototypes"" . Daniel Baumann (chillywilly) said that GNUe Application Server "will do distributed transactions" in the long run. Yurii added "also we used to include strong security from the very start and trying to make a very flexible framework, running on various platforms" . Externally it could support XML-RPC, SOAP or CORBA, but "inside will be an Erlang messaging protocol as a low level protocol" . Daniel said "I didn't know anyone used 'erlang' ;)" .

Further to Peter Dabrowki's comments about SQL-Ledger in Issue�#18, Section�#7� (21�Feb�2002:�ERP Standards) , Christopher Brown said SQL-Ledger was unlikely to want to incorporate standards such as CORBA and XML, as " the amount of infrastructure needed to build such "meta-communications systems" inserts a big whack of complexity. It's not obvious that introducing this complexity actually provides a "return on investment" by providing substantially increased functionality." Todd Boyle felt that more relevant standards for SQL-Ledger would be things like:

He felt that "Vocabulary standards are one of the keys to machine conversations over the internet."

Bajusz Tam�s (btami) said "I am testing forms/designer and made a master-detail form with designer" . However, he was getting a error on the statement "select count(*) from employee_project where emp_no = NULL - I think "emp_no IS NULL" is the correct syntax" on Interbase. Jason Cater said " it doesn't do that with the other databases" . Checking, he found that "it looks like SQL92 defines NULL = NULL " as valid but always false - "but we'll have to work around interbase" . Bajusz cited "A first course in database systems by Ullman-Widom that NULL is not a constans value, and field=NULL is not a valid expression - interbase says too :)" . Peter Sullivan (psu) said he "thought Oracle was the same, i.e. field = NULL is a syntax error" . Jason proved otherwise. Peter said "of course, Mr. Ellison does have several billion dollars weight of argument on his side ;-)" . Jason said "I dunno - gives me a headache - either way, we are fixing our code to remove any ambiguity :)" . He later confirmed the changes had been comitted to CVS.

Derek Neighbors copied the official GNU press release announcing "GNU Enteprise and Double Choco Latte Projects Merge to Further Accelerate Free Software Enterprise Application Offerings" .

" By putting DCL under the GNUe umbrella, additional resources will be immediately devoted to it. DCL and its existing PHP interfaces will quickly be available under the GNUe Application Framework. DCL will be better modularized. Stronger customer management and billing/invoicing by project/work order will be the first of many new features. DCL will become the project management package of GNUe and will use GNUe modules for many of its components."

" The combining of talent from both of these free software projects should only help accelerate the development of much needed free software enterprise applications. By increasing the breadth of enterprise applications that are under a free software license, users are given options to proprietary software that adversely restrict them and their businesses. Adding the additional talent and visions to both projects only helps expand the offerrings of integrated, yet modular, solutions for small to mid size enterprises."

It was asked what impact the re-write of GNUe Application Server (GEAS) would have. Derek Neighbors (dneighbo) said it should have "little direct impact on two tier" . On compatibility with the old GEAS, Derek said "we are discussing modifying the gcd specification some - if we do that then you will probably have some issues" . He said " if your time frame isnt immediate you could wait until the first prototypes of GEAS(v2) start showing up - we dont have a large production geas base, so there have really to date been no concerns about backwards compatiablity" .

1.	28�Feb�2002		GNUe Application Server (GEAS) version 2 Discussion
2.	28�Feb�2002�-�6�Mar�2002	(18 posts)	Using Analysis Patterns for module proposals in GNUe
3.	1�Mar�2002	(2 posts)	Introspection and Designer wizard support for Interbase/Firebird
4.	1�Mar�2002	(1 post)	Data Protection Reports
5.	2�Mar�2002�-�5�Mar�2002	(3 posts)	GNUe Application Server (GEAS) version 2 notes
6.	2�Feb�2002		Object Definition Languague for GNUe Application Server
7.	2�Feb�2002		Integrating Zope and GNUe
8.	2�Feb�2002		Object vs Relational Databases
9.	2�Feb�2002		GNUe web page on www.gnu.org
10.	2�Feb�2002		Debian packages for GNUe
11.	3�Feb�2002		E/AS Update
12.	4�Mar�2002	(2 posts)	ERP standards
13.	4�Feb�2002		NULL fields in Interbase
14.	5�Mar�2002	(1 post)	GNUe/DCL merger announced
15.	6�Feb�2002		GNUe Application Server backward compatability

GNUe Traffic #19 For 9�Mar�2002

By Peter Sullivan