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/.

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"
.

Derek pasted the full list of Goals:

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 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 severalweb 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. 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"
.

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:

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.

"
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"
.