This Cousin covers the IRC channel for GNUe (and most of the mailing lists as well). For more information about the GNU Enterprise project, see their home page at http://www.gnuenterprise.org. Details of the mailing lists can be found at http://lists.gnue.org/mailman/listinfo. The irc channel is on #gnuenterprise on irc.openprojects.net:6667, or you can review the logs at http://www.gnuenterprise.org/irc-logs/.
Kontor (
http://sourceforge.net/projects/kontor/) and Compiere (
http://www.compiere.org) were mentioned as
alternatives to GNUe. Derek Neighbors said there had been some discussions with
the Kontor team when GNUe was started, but the projects had not been merged, partly
due to differences of opinion over Java. Compiere sounded like it was
a 'shrink wrap' style of application [...] While people
like to laugh at the configure times of SAP and friends that is their real power
is they can do anything the company buying them wishes them too.
. However,
he encouraged people to check out all their options
and make the choices for themselves.
Dmitry Sorokin outlined the changes that let me
use gnue forms under GNU/Linux and windows with non latin1 charset
(in his case, Cyrillic).
Later,
on IRC, James Thompson (jamest) said
I'd like to support i18n with any i18n features built into the UIs and python itself
- maybe via unicode input scanning
.
Derek Neighbors (dneighbo) said I was going
to compile a comprehensive list of report objects which woudl translate to
tags/attributes
for XML. Derek gave some examples. Jason Cater said his
and Michael Dean's ideas had been similar, they had just used different
terminology. Derek said he had used Quickreports, but would welcome input from
people who had used packages like Crystal Reports as well, to
see what's missing, what's stupid
. At this
stage, this was reference material, not a proposal. Later, he admitted
the part I'm torn on is we have two phases -
pre data population, post data population - some of these are needed pre
and some post and some both
. It was not clear whether items like
page numbers and orientation should be part of the XML, as they were
display-dependant.
Michael Dean (mdean) reported a conversation he had had with Derek
Neighbors (dneighbo) on another channel. He had asked if
GNUe is to be language independent, how will you implement triggers
?
Derek said that there had been a lot of discussion about this. He remembered
the thing we all agreed on was that we want to make
a trigger/event system that is shared by the appserver and forms
.
Michael suggested XML. Derek said this had been discussed, but
it just didnt sit right in fleshing it out
. Later on, he pointed people to
http://lxr.gnue.org/gnue/source/gnue-common/doc/TriggerSpecifications.txt for more details.
Later, Daniel Baumann (chillywilly) said his proposed plugin system would
remove this issue. Jason Cater (jcater) said this was different -
we have to have a common way inside those languages to
identify our objects
. Daniel suggested GObject
bindings ;)
. Jason later remarked however
we maintain our object references, we have to answer the question
of how will the objects be represented in the language's namespace and how
will those references tie back into the forms, geas, or reports
instance
? He liked the look of GObjects, however. Perry Lorier (Isomer)
suggested for a v1.0 release, python only bindings
IMHO is perfectly fine. Add perl, php, C, C++, scheme, visual basic bindings
for v2.0 and rev quickly :)
James Thompson (jamest) pointed out that you could not store a GObject in a
database. He said GDataObject is IIRC the
starting point of our data aware system
. Daniel asked if this
meant re-implementing GNUe Application Server (GEAS) in GNUe Forms
- GEAS is essentially GObject and
GDataObject if you really think about it
.
Two days later, Derek (derek) suggested supporting spidermonkey.
Michael supported this, since it would make GNUe
web forms triggers almost no-brainer
. Derek clarified
the idea was to make it so each development house
wouldnt have to learn a 'new language'
but could use their personal
preference - our base packages will be python
triggers but we want to let any language be used
. If someone had an
exisiting system in, say, perl, it might be easier to
reuse a good portion of my code in gnue as well as not have curve of learning
python
. Jason pointed out that if someone
is simply wanting to extend our packages, they wouldn't have to rewrite the base
in their language
- they could mix and match.
The next day, Nick Rusnov (nickr) confirmed that xml
is used heavily throughout gnue
. Perry Lorier (Isomer) said
no databases support XML transactions
-
apart from Microsoft SQL Server 2000, as Michael Dean (mdean) pointed out.
Reinhard Müller (reinhard) said we are doing xml
from database in the reports module
. They had
looked at the xml query language from the gnome-db
project and we decided to stick with SQL for the db access because SQL is
sufficiently standardized and supported natively by virtually every db
.
James Thompson (jamest) said they were doing a new release this weekend,
and wanted to include madlocke's code. Michael Maluck (madlocke) said he
needed to discuss a few problems first. His postgres wasn't asking for a
password, as it had not been set up that way - he suggested having a
UILoginHandler in a base class or as base class
. James agreed. Michael said the UI code can
display most things... the last I did was data exchange... some things
work... buttons work...
.
Three days later, in a discussion about Webware, Derek Neighbors (derek)
said they were looking to use webware for UI
driver [...] that madlocke is working on.
GNUe Forms is designed
work with any user interface that there is a driver written for.
Now the killer thing is if you use something
python based you can use all underlying objects
and just reimplement
the driver.
The next day, Michael said he hadn't been able to commit his code yet,
as he was having to use WinCVS to checkout
and was getting conversion problems with carridge returns/line feeds. Derek
(dneighbo) asked him to e-mail the code. Michael said there was a problem, in
that the only relation between labels and entries is
position on screen
. Derek said we should be
autocreating the lable based off a property
of entry
.
Dmitry Sorokin (ra3vat) asked do I need separate
driver or something to use gnuef with mysql, both on windows?
Jason Cater (jcater) said I don't think the mysql
drivers work on win32 without modification
. Later, Derek Neighbors
(derek) said he wasn't sure that the mysql
drivers for windows 'native'
had ever been tested - the generic
Windows ODBC drivers had been tested, but a long time ago. Dmitry was
also having problems with using GNUe Forms with postgres on Windows.
Derek wondered if this was a TCP/IP probelm. Jason and Dmitry swapped
error messages and the set-up information in an attempt to solve the
problem.
Derek Neighbors (derek) said the scoop is we
have some one graciously paying a developer to work on gnue in lithuania
now
.
Two days later, Derek said that now we had a full-time developer.
we REALLY need dcl
- especially if we get college interns
.
The next day, James Thompson suggested some things
intern and full timers could do
, both new tasks and current.
Daniel Baumann (chillywilly) asked if
GNUe would benefit from using
the XForms W3C standard.
Charles Rouzer (Mr_You) it probably
wouldn't be hard to integrate X-Forms clients at somepoint, or redo
GNUe Forms to use X-Forms methods instead
.
Later, Daniel asked if X-Forms was feature
filled enough
to be used for GNUe Forms Definition
(gfd) format. James Thompson (jamest) said it had
too much complexity for our target
application
. Derek Neighbors (derek) said
It's standard in sense its submitted
to a 'standards body'
but no-one was using it. Daniel
replied that mozilla
was
implementing it. Derek said he liked XUL, but did not
think it fits with what we are
doing
.
Oliver Vecernik reported some errors running GNUe Application Server
(GEAS) from cvs. Reinhard Müller said that
I think the reason is that you entered
a non-numeric string when asked for the weight.
Oliver also asked Is there a step
by step instruction
for producing classes and testing them in Python.
Reinhard said To produce classes you need to write
.gcd files. For the python test you could refer to the samples
or
suggested joining the IRC channel. Oliver also asked
How to shutdown GEAS correctly?
.
Reinhard said the kill command was the only way -
we will add some better way someday.
Later,
on IRC,, Oliver (ov) asked about the status of methods in GEAS.
Reinhard (reinhard) said to be 100% honest
methods are already implemented but in a way we are not happy with and
e want to redo the implementation so we don't tell you :)
Later,
he added forms and reports seems usable
in the state they are now. GEAS was contributed by a company and we
are now in the process of going through the code and adapting it to
our needs wrt maintainability, performance etc.
Oliver asked
is there a possibility to write
businessobjects for 2 tier and port them to geas sometimes?
James Thompson (jamest) said it depended. We're
going to try and share trigger/method system - if it works then
I think you could at least share the methods - the object definition
isn't possible now
. Daniel Baumann (chillywilly) said he
thought forms could play with objects too
and they can execute on the client side
. Ideally, the
GNUe Common package should handle all of this, and
you shouldn't even have to know that the
objects are remote objects or not
.
Alan Clifford asked What is the implementation plan for
GNU Enterprise?
Derek Neighbors said A
roadmap for the tools has just started to take shape.
Although the applications side had lost some focus, I
think we have some consulting jobs that will push feature sets here very soon
though.
General Ledger, Accounts Payable and Accounts Receivable were the
logical starting point, but I think 'real world' demands
will pull us in other directions. Mainly invoicing (billing) and CRM.
Alan asked Do you plan to do an overall design before you
start implementation of components?
Derek replied
Yes and no. We were running thought of TWO tracts.
One tract is the pie in the sky fleshing out of the package/module with review
from lists etc and incorporation as the 'official GNUe' piece for said item.
The other tract is demand based consulting type stuff that will be
contributed back for redistribution but will not be 'official'.
This comes because we have some real consulting demands that will not
allow us to do it the 'offical' way, but will likely produce usable for
others software. We have always had the notion of 'official',
'friendly', 'unfriendly' etc types of packages.
Alan volunteered to submit one page descriptions
of various packages so you can replace the "This is the x package"
messages when users click on the GNUe package names on the "gnuenterprise.org
" page.
Derek said the documentation was done in
docbook.
You can find the source for the documents
in the CVS tree.
He encouraged Alan to submit a proposal for Accounts
Payable, using the other proposals as a template. Neil Tiffin said
Email the proposal to me in any text based format and
i will circulate it and put the relevant details on the web site. Please
feel free to submit AP or improvements in AR and GL. The current
specification are not rigorous and need a lot of work.
James Thompson (jamest) said we can now
have a setup.exe for forms and designer. However we should probably come
up with a default install behaviour for gnue tools on windows machines
. Some files needed to go into C:\WINDOWS\SYSTEM, others to
C:\Program Files\gnue. Jason Cater said an
alternative installation scheme would be to have two installation
.exes
, one with just the client software and another one for full
development. James said the environment variables should logically go in
the Windows Registry, but no-one was very keen on this, because as James
himself pointed out as it sets we
should be able to network install this puppy - registry
hacks make than tougher
. So for the moment, the client applications
would just look in their own directory for files.
Later on, James confirmed that they were using inno,
a free installer for windows - takes a script
and makes a setup.exe from a bunch of files - with the files we have gnuef
and designer are setup.exe's that install and uninstall nicely - just got
to work some kinks out of the system
. He later said
we're currently looking for a win32 install
maintainer
, but there were no volunteers. He finally got the GNUe
Forms install working, with some minnor issues to
work out
.
The next day, Derek Neighbors (dneighbo) was
testing windows installer
.
James was hoping Derek
would do up a little intro form
as
there were no sample forms included at all yet. Derek requested that the icon
for the GNUe Forms client should point to a
default sample form
. Later, Jason confirmed that the sample files
had been added as a selectable componant, and said
our windows setup rocks!
Derek said he wished
we could make the unix setup that damn clean
and good looking
. But using apt-get would tie people to Debian,
and most other solutions were proprietry. Perry Lorier (Isomer) suggested
setup.sh isn't a bad way either
.
James Thompson (jamest) did some final tidying up for 0.1.0 with Jason
Cater (jcater), and said so we're pretty much down
to doc updates now right?
. Later, Derek Neighbors said
we need to make a 'manual' for designer that
has 'pictures'
, but for 0.1.0, the Technical Reference would do.
James suggested including a URL link to the docs
then they are always up to date :)
.
Later, Jason said I still can't get lyx
working
. James said I've written 3
chapters of a manual while he's trying to just get the dependencies
.
Derek said he'd rather the screenshots did not imply preference
for one desktop over another :)
to avoid holy wars over the merits of KDE, GNOME or even Microsoft
Windows.
Jason Cater (jcater) said he had set up a form that
is pulling data from an MS Access database via ODBC
.
Derek Neighbors (dneighbo) said the reason
this is cool as now we know integrator can be made to convert people from access
to postgres :)
Later, Jason confimed he was working on native drivers
for Access, as ODBC drivers will not support
introspection (so designer won't be quite as impressive running via ODBC) -
but running native against MS Access/SQL Server/FoxPro with full schema discovery
- that's an upgrade path :)
Dmitry Sorokin (ra3vat) asked how to pass additional commands to the database
after getting a connection. Jason Cater said If you are
having to customize one of our drivers for your environment, then we may need to do
something else
Dmitry said he needed to SET
CLIENT_ENCODING TO 'WIN'
for his set-up. Derek Neighbors (dneighbo) asked
if this should be another item in the connection
file?
Jason agreed, and quickly made the changes and committed them to
CVS.