This Cousin covers the three main mailing lists for the GNU Enterprise project, gnue, gnue-dev and gnue-announce. 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. For more information about the GNU Enterprise project, see their home page at http://www.gnuenterprise.org.
Malek Hadj-Ali asked why
aren't you guys using Zope as an application server?
It has a lot of features that could be reused (ZCatalog,
ZSQLCatalog, ...), it's written in python, it has a big
community of developper, and so on...
Stan Klein noted that, according to their web page,
Zope has a standalone persietent
object database
and They
can evidently use other databases as backends, although I
didn't see reference to any of the ones GNUe is
using.
Jason Cater said
Several of the core developers
use Zope as web/portal servers at their places of work.
GNUe is even switching to a Zope backend for our
website.
But his perception was that Zope was more
targeted at serving web applications
/ content
than the sort of Application Server
that GNUe needed for GEAS. Todd Boyle
said that he didn't seen Zope as incompatible
with any of the higher goals of
GNUE
and GNUe could tap into the
huge amount of work
already done on Zope. As they were aware of Zope, he
wondered WHY the GNUe developers
rejected Zope
, guessing at some possible
reasons.
Jason said that GNUe was not primarily
a web-based application
.
However, it would be possible to have
a web-based application server as the backend. We've toyed
with the idea of supporting JBoss and (somewhat) Zope as
backends, but nothing has come of this as our resources
are very limited.
.
He felt that Application
Server is very much an over-used term that has little
meaning these days
, describing
anything from a web portal to a
business rules server to a database proxy.
Zope
was a type of application server,
but I don't see too much overlap in goals
with
GEAS, which was a a business
rules + data server.
He felt that GNUe Common
already provided pretty much
what the "core" of Zope would provide
. He
concluded My toilet paper dispenser
is an application server. So is my refrigerator. I try
not to confuse the two, though.
There had been
some discussions with the DotGNU
folks about them reusing parts of our Application Server
for their .NET replacement
, but once again he had
some concerns that the "Application
Server" phrase around is causing the same confusion in
this case.
He re-emphasised that
several of us use Zope in our professional
settings
and absolutely love
it; but, I love it for what it is -- a web-based content
server.
Zope as the leading
example of python programming for some time now
had
directly benefited python-based projects like GNUe
from any contributions they've made
back to the python language and python's extensive standard
library.
.
Todd asked how would you
advise somebody already committed to Zope to achieve some
basic accounting needs?
Peter Sullivan said
Theoretically, you could
re-write the existing Forms client in Zope
as
they were both python applications. This would give Zope
the ability to use
GNUe Common to talk to multiple databases
and
later, to use GNUe Application Server. However, he
was not sure this was sensible.
Earlier, Jorge Lehner said he was currently using Zope for a
Practice Managment Tool
,
and listed some of the problems he had with it,
concluding That is, why I'm waiting
(silently) for Gnue to come up with a stronger and more generic
framework for business programming.
He added that he,
too, liked Zope a lot for what it
is.
Abdul Hafiz Abdullah noted that Zope's license
was GPL compatible but its
too generous ala BSD, X11.
He preferred the GNUe
Public License, as used by GNUe,
that will protect our
freedom.
Harald Meyer (Harald1) asked where
are the methods of business objects stored
in GNUe
Application Server version 2. Reinhard Müller
(reinhard) said along
with the class definitions - we haven't set it in stone but
i strongly believe it will be in the database
.
Yurii Rashkovskii (Yurik) asked you
mean you'll store code in db?
. Reinhard confirmed
this - gcd or xml will only
be a means to trasport it - but at runtime all this will
come from the db
.
Harald asked are the set of
language for methods implementation a limited one?
Reinhard said that support for methods written in languagues
other than python is very low on
priority - and i'm still not sure if it makes sense to support
compiled languages for methods
. Yurii suggested this
might be important for
the time-critical methods at least
.
Reinhard said that two appservers
(with load balancing)
could have different operating
systems or processors, which would make compiled method code
impractical, and i don't think
compiling method code gains much performance - as opposed to
for example optimization of db access
.
Harald asked if thie meant that
if two business objects have some methods which are identical,
these have to be stored twice?
Reinhard said yes,
but this won't be the case very
often (imho)
. Yurii said that, on his project,
attributes & methods
are separated. methods are just reffered from the database to
their location at services that run that methods - so method
could be implemented in any language - the only one thing is
that this method wrapper must be able to talk w/ its
service
He felt that
storing code in db is a bad idea
.
Harald said he did not have
anything against storing the code in the db. but what I
think would be better: don't store the methods with the
objects, but just referr to them
.
Yurii asked whether GNUe Application Server would
start method code on each
request for this method execution?
Reinhard said he
was not sure, but
i think we
should aim at something like - method code can be dynamically
changed while server is running and on next invocation new code
is active - but appserver caches method code and if not changed
then it can use (precompiled) version in cache
.
Reinhard said that a lot of these issues could be
reviewed once they had some working code, and could see the
impact of different ways of working -
we can discuss about the best way
to store methods for 3 years and not write a single line of code -
i know it because the gnu enterprise project worked like this for 3
years until derek came and kicked our butts :)
. Different
people had different ideas about how things would work as of time
of writing.
Harald asked can/will business
objects run automatically or only if the are controlled by a
user?
For example, automatic re-ordering of products
that fall below minium stock levels. Reinhard said that business
objects do not act, they are
acted upon
but invoked
by the user or invoked by cron doesn't make much
difference
. Harald said he hadn't been clear about
what a business object was from Reinhard's whitepaper.
He asked whether the data itself is
part of the business object, or is it just the definition of
the data?
. Reinhard said that
business object can actually mean
both
- he preferred the terms
a business object class or
a business object instance
where a distinction was
needed.
Derek Neighbors (dneighbo) announced
we have our booth officially now
for
Linux World Expo in San Fransisco -
.ORG Pavillion Booth #6
.
He noted that this will be 4th LWE
we have had booth at - 2 NY and 2 SF (though no one was able to
man the booth last time at NY)
.
John Lenton (Chipaca) reported we've
been fighting with datasources, cursing that you can't
make one access two table at the same time... ...only that when
we were over at my place last night talking about stuff we realized
that no, datasources *should* be stupid, because it's the
appserver where the intelligence belongs
.
Reinhard Müller (reinhard) said that
some basic functions will be
usable
in GNUe Application Server (GEAS) in about a week.
Derek Neighbors (dneighbo) said i
dont think geas is your answer - if the datasources dont do something
you need let jamest or jcater know - as GEAS is SUPPOSED to use the
common data level - which means datasources and such would be the
same
.
Later, Jan Ischebeck (siesel) said I
think that in a 3-tier environement the client=forms should as light
as possible. i.e. in 3-tier env. forms don't need views or something
like that. views would live in the middleware = geasV2
.
However, if views could be added to the
db abstraction layer in common, to make 2-tier support this too. would
be great.
John felt nobody
should be building 2-tier apps :)
Jan said
gnue will give you the choice. ;)
.
However, There will be a point where some
features, f.e. views, transactions, locking... will be quite difficult
to add to the db abstraction in common, and where its more praticable
to move it up one layer. just because of programming issues.
John suggested in a 3-tier app, i.e.
with geas, all i have to do is define the 'view' or whatever and i'll
be able to access it from the forms as if it were a table? and this
will work even if geas is using a db that doesn't support views?
and the view will be defined in some xml format?
Jan
agreed - but don't expect that feature
for geas v.0.1 or 0.2
John said we're
willing to make them happen :) i.e. code them ourselves
.
Joe Konecny asked Is the
GNUe project actively being worked on? I looked at the
IRC logs and it really looked like a joke.
Chad Walstrom said that CVS commits were probably a
better guide to the level of development activity.
He added that the mailing lists were
usually less "off-topic"
than an IRC chat room or log file
, and also
recommended Kernel
Cousins. Derek Neighbors agreed that
IRC is 90% joke and 10%
development, but still the majority of the development
design work is done there. One thing you will find with
GNUe is that there are a lot of 'professionals' who
quite frankly started GNUe to work in an environment
other than whatthey get paid to work in. (read there
is great enjoyment in the community) So yes IRC might
seem childish and full of mindless banter, but it is
fun. :)
He also noted
CVS commits happen daily
in volumes larger than most Free Software
packages.
It was asked if Designer could be used to change the table
structure in the underlying database.
Jan Ischebeck (siesel) said if you want
to change your database structure, you can't use designer for that
task (yet :)
. For large applications,
he said currently, we are all waiting
for the application server, which sits between the forms and the
database - when it is usable, we can write big applications on top
of the gnu enterprise tools - but you can use current gnue as a ms
access replacement very well - there are some in-house applications
written by some core team people
. He explained that
gnue reports makes heavy use of sablotron,
which is an xsl transformation processor. it processes xml->text and
xml->xml - thus, you have to install PySablot (the python binding for
sablotron) to make Reports work.
. He confirmed that the
GNUe tools were all written in python - it's
a really fine language
. He confirmed that
XML made by Designer is stored in files, but
there will be facilities to let it reside on the server as well
.
The validation code doesn't have to be copied
into every forms definition file
, as it was part of the Forms
client.
Marcos Dione (StyXman) said he had added a
new widget. I modify GFParser. I modify UIdriver. what's next? I mean,
*how* do I say that this new GFj uses UIj as visual
representation?
Later, he suggested could it be the WIDGETS
hash @ the end of UIdriver? says it's for designer...
Jason Cater (jcater) arrived and said
UIwxpython
. Marcos felt
it's incredible how a word, a simple word,
can change you whole mood.
Jason said
dare I ask what you've added?
Marcos said it was just an icon he had taken
off the maintoolbar
as we think it may be confusing to inexpert
users.
John Lenton (Chipaca) asked btw,
is there any reason the widgets all require x and y attribs?
Jason Cater (jcater) said this was for positioning. John asked
can't that be done automatically?
.
Jason agreed,but said we have better / more
important stuff to do than layout management
as of time of
writing and we get the most bang for the buck
w/ x,y
in the meantime.
Marcos explained in detail the changes he had made to support
his new widget. Jason said there was nothing obvious he had missed.
Marcos said he was getting an error, which he pasted. John
felt it was a parser problem, but Marcos was not so sure
- if it would be a parsing problem, it
should die saying so.
He pasted some more information
in the #flood channel.
Some days later, Marcos asked if I
develop a new widget, what exactly should I do in
forms/uidrivers/_base/UIdriver.py?
Derek said that
if its a widget that will be fully
supported by GNUe long haul it would go same place as others
.
If it was an 'unofficial' widget as discuseed in
i think it will be handled
differently
.
Marcos said he was trying to
understand a GFUserInterfaceBase - it has the _formToUI and
_formToUIWidget hashes, along with widgetConstructorFunction.
The latter seems what I need, but I'm not sure.
James Thompson (jamest) explained _formToUI
is the form tag to UIfoo mapping - _formToUIWidget is the mapping to the
numerous widgets that can be created by a single UIfoo instance
.
Marcos said he was almost there. James went on to explain
right now the entire ui system is created
from the gfobject tree built by the parser
. However,
this sounds different though
. He
suggested i'd think you could easily add
a another phased init stage in the form itself
but quickly
changed his mind. Marcos said he could not work out why the container
for his new widget is a wxPanel...
He explained _createWindow is called with a
container param. the one passed to my _cW is a wxPanel. should be a
sxForm, I gues...
James said IIRC
the wxForm contains a pannel...i think this is some kind of
wx'ism
but he was not sure.
Reinhard Müller (reinhard) asked is
there something special about variables in python that begin with _?
or is it just a matter of style to name "private" variables with _xxx?
(from my understanding python doesn't have the concept of "public"
and "private" members in objects)
. Jan Ischebeck
(siesel) said if I remeber right _xxx
is the a style to name "private" methods. There is an other kind of
pseudo "private" methods called __xxx (without __ at the end like
python buildin methods like __getattr__) - what I know for shure is
that some gnue code is depending on the _xxx convention to
distiguish private and public methods, like GNURPC is just exporting
methods without one "_" at the beginning and GTrigger (if I remember
right) uses a similar thing too.
Reinhard said he thought
it is a good thing anyway IMHO -
i just wanted to know if it's a syntactical thing or "just style"
.
He also asked when are python
objects destroyed?
Perry Lorier (Isomer) suggested
when their refcount hits 0 I presume
.
Jan added and the garbage collector is
aactive
. Reinhard suggested that we
need some code to close the db connection for a geasList instance
sometime - when we have the list of active geasList instances all
geasList instances remain referenced as long as the session is
active?
Jan confirmed this. Reinhard said he was just
trying to do sort(brain);
Jan suggested don't use bubblesort use
quicksort. ;)
Reinhard suggested that when
the form is closed then the session is destroyed
. Jan said
for forms it is no problem, but
Designer might create more open connections, and
if you use designer a longer time it
will create heaps of old geasList objects.
. Reinhard
suggested that Jan should take the
glory ;)
and commit the changes to CVS. He asked
for clarification about Designer using multiple connections.
Jan said that If you use Postgres as
DBdriver there will be only one connect per programm start
but this might not be the case with some of the less functional
drivers.
Jan said that the biggest problem he could see with GNUe
Application server was implementing GConditions -
I thought of adding a "without
GConditions" to the v 0.0.1 entry in the ROADMAP.
Reinhard asked does appserver work
with released common? or would we have to do a common prerelease
at the same time?
Jan said appserver
needs the "dbdriver/appserver" from today. but it should work with 2-3
weeks old GNURPC.
Reinhard said the last release of GNU-RPC
(GNUe Common) was significantly older than that, and a new release of
the two-tier tools was imminent. Reinhard said
i don't think we will release appserver
0.0.1 together with the new forms release
, but Jan said that
depended on how soon the next Forms release turned out to be.
Reinhard said that, for Application Server,
i think we should release what we have
as 0.0.1 - maybe add a little testing before - but then we would have
to talk to jamest/jcater to do a common release at the same time
.
Jan said I just thought it would be good to
have a already released common to use. i.e. we just would add some wrapper
code to the new appserver 0.1 to be compatible with the ugly dbdriver/appserver
implementation of the already 4 month released gnue-common
.
Reinhard was not sure if i like that idea -
what about helping jamest/jcater to get current common out of the door as
say 0.1.90?
. Jan liked this - possibly its
more clean to release a new common at the time of releasing appserver
0.1
. Reinhard said this might allow a co-ordinated release of
common 0.2.0, forms 0.2.0, reports 0.2.0 and
appserver 0.1.0
, either all at once or planned over a few days,
in the same way that the Gnome project released.
Reinhard said he would do some
testing for appserver - and update the docs (fwics the api has changed
slightly)
. He added from what i
hear the release of common isn't delayed due to lack of function - but
rather lack of time - so if we help them in the release process we could
speed it up
.
Later, Daniel Baumann (chillywilly) said that for
a builtin-in method in python to destroy resources (close db connection) I think
you can use __del__ - that method is called before the object is garbage
collected, afaik. Also, for private attributes starting with "__" is sorta
private in that they get mangled like self.__attribute is mangled to
self._Class__attribute - attributes
like _attribute are just a convention
that means hey don't use this directly....I sort of think of them as
"protected" attributes
.
Reinhard clarified that the first release would
have
no object description
, but this would be added for future versions. Jan
did some work on the driver to link the Application Server to Forms. Reinhard
suggested some directory name changes to avoid confusion with the driver for the
old, depreciated, version of GNUe Application Server (GEAS). He had
tried to run the geas server and the geas client on
two different machines - where i found out that i can't do this because i don't
have 2 machines w/ python 2.x :(
. Jan and Reinhard did a test together
using https:// over the internet. Reinhard remembered that
iirc geasv1 took over a year until it worked with
forms this way
and suggested setting up
a demo server
for public access. Jan said this might be
a 'little' security risk.
Jan asked do you have any ideas how to send
conditions to the appserver?
. He said if I
understand it right the actual conditions which will passed to GDataObject are
some kind of object tree. Which would be a bit complicated to transfer over
RPC.
He suggested that, since GConditions are
single statements which are connected with "AND"s and "OR"s
then
why not transform this conditions in a standart
form (a^b^c)v(d^e^f) going this way we would just transfer a table instead of
an object tree (a AND (b AND (c OR d)))
. He thought that, both in
principle and in practice this would not be a problem, because this was how
Forms worked - We take this table and transform it
back into a GConditions object tree.
Reinhard said that there could be
peformance problems with complicated Boolean logic, but most business
applications
in practice tended to use fairly simple conditions. The other
approach to passing
conditions to the Applications Server was to pass lists.
He explained my thinking was to make the
method to create a new instance of a class - not be a method of geasList -
but of geasSession. But now i see that it makes sense to put it into geasList
when i think about how forms works
. Jan said
to be honest, I don't like to have it in
geasList too. but geasSession isn't good either.
Reinhard
said it made sense because geasList is the
list of instances that can be scrolled through in the form
.
Jan suggested I would like to have a
geasClass in between, which also holds the class definition and can create
new instances - it doesn't have to be a member of geasList, because every
new record in forms stores an pointer to the new created geasInstance,
but I still would seperate the functions which are in geasList now into two
classes.
Reinhard said he wanted to keep things simple.
Jan said If I create a new list, just by
executing a query. then it really should be a new List and not the same
list populated with new values.
Reinhard did not see why not.
Jan said it is ok, if you have just one client
which access only one table at one time. I would prefer a geasClass which
could generate Iterators, or something like that.
However, they
both agreed it was more a matter of personal taste/programming style.
Reinhard did a todo
before 0.0.1
list:
- test, try to make appserver so stable that it doesn't traceback at all
- find out what the variables in __init__.py are for
- write a "setup.py"
- write an "INSTALL"
- release gnue-common [...]
- extend test.py to show more features
The next day,
Reinhard Müller (reinhard) reported good
progress :)
on the GNUe Application Server re-write -
you can use appserver for remote data
access without methods - it simply passes through the data requests to
the database
. He admitted doesn't
sound sooo great - but if we are honest then it's virtually as much as
you could do with geasv1 after 2 years of development :)
He said we want to do a 0.0.1 release before
we implement more stuff - we might implement conditions
before 0.0.1 - however we must wait for a gnue-common release with gnuRPC
before we can release appserver - because appserver depends on gnuRPC
.
He encourged people to simply test what we have
and tell us about bugs :)
Jan Ischebeck noted that At
the moment the commdrivers directory is not added if a new
release is created with common/setup.py.
He
suggested that, now the comm drivers were alpha status,
they should be added to common
to make the use of appserver etc. possible.
Jason Cater said It was merely
an oversight that setup.py doesn't install
commdrivers
, and applied Jan's patch.
Bajusz Tamás (btami) said Firebird was his favourite database -
becouse it's better then mysql, and have
native win32 version
. It was, if anything, easier to
administer than MySQL, and was only a 2.5 MB download from
Sourceforge.
Later, Jan Ischebeck said he had had
a look at btami's patch for dbdriver/interbase. It just adds trigger
functions (similar to the ones in dbdriver/_pgsql) and won't
make the basic driver getting unstable or something like that
,
so he would prefer to apply it now rather than after the current
codefreeze. Jason Cater (jcater) said I've
already added it - like 4 minutes ago :)
Jan asked what still needed to be
done before the release of common?
James Thompson (jamest)
said i'd like to look into some issues
w/ number fields (common/forms interaction) - but honestly that's
looking like next weekend and I want to release so badly
.
He wondered if claiming that now that
we're known for working on GNUe our lives have become one non-stop
party
might help us attract more
developers :)
.
John Lenton (Chipaca) asked why can't
I specify the user in connections.conf?
He was getting tired
of the login screen. Jason Cater (jcater) said we
were, um, being security conscious
, adding
we were planning to add
netrc
support iirc
. John also noted if you quit
a form before the splash has gone away it *hangs* !
Jason said
err - we know :( - it's a wx bug
and
there was both a command line option and a
gnue.conf option to shut
the splash screen
off for that very reason
.
Derek Neighbors (dneighbo) said he thought that putting user names
and passwords into connections.conf would be a
bad thing to do
. John said he appreciated the security issues for a
live system, but when I'm developing something and
I don't have a password on the database in my closed LAN
it was
more important to be able to get in and out of test forms quickly.
Jason still was not convinced, but said
if it were added to connections.conf,
then GConnections.py is the place to add it
. John asked about using
netrc instead. James said i would think that
netrc would override connections - so the user could override the system
default
. John said I'm thinking about how
to specify the hostname - I think it should probably something like
gnue://host/provider/dbname/ - which leaves me with this ugly feeling of
netrc not being the right place for it :)
.
Derek siad that hardcoding usernames and passwords was better
done using command line parameters -
and alias you shell to always fire those
- a command like
frmdev aliases gfcvs -u chipaca -p
mymomma
. John said he did not like this. Derek said he
thinks its not a good idea to hard
code at all
, and that putting it in connections.conf was
just as much hard coding as his idea. John said it was
hardconfing
it -
if you put it in your text configuration
file, it's the UNIX way
. Derek said
i would rather see someone work on
integration instead - where it uses your system login first -
and only if that fails does it prompt
. John claimed
I'm scratching my itch :)
but
he would look at that next. Derek said
i think with ERP type applications
you shoudl be challenged regardless and never trusted
but
i suppose tehre is no evil in letting
connections.conf do it - as its optional. i just dont like to
encourage it
.
He felt i think a good compromise
might be 'remembered' userids by machine. So if i come in and login
as dneighbo - next time i fire up forms, dneighbo is automatically
entered into the user field - and just have to type my password - but
if im not dneighbo i just type my userid and password
.
John did a quick fix using netrc, which seemed to work, and submitted it as a patch.
Alejandro Pronotti (aprono) asked How
do I do to add an image in a button?
James Thompson (jamest) said
that that isn't supported
for Forms
buttons - Daniel Baumann (chillywilly) suggested that the toolbar buttons
were hardcoded I think
by wxPython.
Alejandro also asked about binding a
keypress to a trigger?
James said at
one time this was possible but i'd have to look in the code to see if it still
is
. He appreciated that there were a lot of things hard coded in
Forms, but this was to fit the design goal of
forms - we are not building a
more generic tool like
glade
.
Bajusz Tamás (btami) asked can i use
firebird or just postgresql
as the back-end database with
GNUe Application Server (GEAS). Reinhard Müller (reinhard) said
that you should be able to use
firebird
as GEAS now used the database drivers in GNUe Common -
however the sql script to load the inital
test data into the database does only exist for postgres
as of
time of writing, although it could be easily re-written for any
SQL-92 compliant database. Bajusz asked how
appserver knows wich db i use
? Reinhard said that
the connections.conf file needed an entry adding for [gnue] -
this is what made GNUe Forms talk to the Application Server
(n-tier) rather than directly to the database (2-tier).
Bajusz and Reinhard did some more testing, sorting out various
error messages along the way. Jan Ischebeck (siesel) said
we need a appserver.conf file soon.
I will add some command line options as a first step
.
The setting to tell GEAS which database driver to use was
in geasList.py - but there will be a
command line option soon.
Later, Jan asked does appserver needs
a special configuration file or should it use gnue.conf?
Reinhard said we have to take into
consideration that on most installs that use appserver forms/reports
will run on different machine than appserver - so i would think it
makes sense for appserver to have own config file
. Jan
suggested putting it into the roadmap for version 0.0.2.
He was not quite happy with the
appserver/INSTALL file in its current state. Whats about adding a
SETUP, TESTING file or should it be in the
appserver/doc/appserver_user_manual ?
Reinhard said
i think it's ok to have instructions
for basic tests in INSTALL - for example say 1. setup.py 2. run
test.py 3. run geasRpcServer.py and geasRpcClient.py just as a part
of the install procedure to see if the install was successful -
anything further should go into doc/manual IMHO.
There
might also be specific install documentation for CVS versions
that is not distributed in releases
and explains the g*cvs commands
.
Later, Derek Neighbors suggested please
make the sql script to load the initial test data as xml under our data
definition markup and then it would support more than postgresql
:)
Reinhard said he had not been aware of this.
Derek said it was not fully documented and
i dont remember if its in GNUe cvs - as we started it for DCL and adopted
it
. It used pysablot and
sabolotron
to convert from XML to a database-specific script using
XML style sheets. He explained basically
this way you only have to write the table definitions 1 time (in xml)
- and the create scripts for all the dbs are created automagically for
you
. He believed that you could also use it to fill test data
or standing data into tables. Reinhard
suggested that, for official releases, as well as the source XML, the
post-processing version for the main supported databases should be
included so one wouldn't need
sablotron to test appserver release
. Derek agreed -
in dcl we even put them in
cvs
for the same reason.
Christian Selig (lupo_) said he was searching
the web for "raw data"->"graph" progs - what are the current output
formats of reports?
Perry Lorier (Remosi) suggested
gnuplot
, but Christian pointed out that
it doesn't speak svg :-/
. Perry
said it does speak png
, although
it would be nice if it output something
vector like
. Christian said it could
output eps
.
Batik, from Apache.org was suggested as an alternative, but
Christian noted it was written in Java
.
He noted that
plotutils
sounds nice
, and had not one but
two python interfaces -
http://biggles.sourceforge.net/libplot/ is the URL for a python libplot
interface - and it looks quite human
.
Bajusz Tamás (btami) noted some updates needed to the README.databases file, which specified the functionality of the various database drivers in GNUe Common:
- MySQL has introspection
- SAP-DB too
- SAP-DB has win32 binaries
- interbase version is 6.x, not 7
- interbase provider is interbase, not informix - and all informix=interbase in the interbase section and kinfxdb=kinterbasdb
- interbasdb is tested in win2k,debian
- pyrgesql description: section is outdated
Jan Ischebeck asked what is outdated
in the py resql description? Should it totaly be deleted?
Bajusz said he thought so, as it is
DB-API 2.0 compliant now IIRC
.
Reinhard Müller (reinhard) asked Derek Neighbors (dneighbo) to
please check if
the Free
Software Foundation (FSF) had received a couple of copyright assignments.
Derek was able to check the status straight away, as the FSF was now
using DCL for its own internal "to do" lists. He said
i think once we get in swing of things
with dcl and add some functionality - it will be REALLY powerful for
free software projects, including the GNUe project itself. He was not
sure why the SSL (Secure Sockets Layer) certificate on the GNUe project's
DCL install was showing as expired. However, if people didn't like the
default font size, good browsers such as galeon
will let you size font to whatever you
want :)
.
Christian Selig (sledge_) asked btw,
whatz the release plan?
Derek Neighbors (dneighbo) said they
had hoped to do a release last week
for forms, reports, designer, common
,
but this had not been possible due to other commitments for team members.
He thought if i could find a windows tester
we could probably bundle some stuff and check it out - i.e. test it - if
it works well we release
. Otherwise,
i think the best course of action is to
probably create a branch for the release - and go ahead and have at
head - and when life becomes sane then tackle a release
. He
noted generally the things that hurt us
release wise are getting docs updated and getting things tested - we
have a lot more people with installed systems so it should be easier to
get 'testers' :) - early releases im not too worried about docs, but
they are nice to have - we definitely need to get road maps rolling for
all products - with feature lists by release
- and use the power of cvs to branch/merge as necessary to not
kill release cycles
. Previously, this had not been an issue,
as not many developers so we could safely
not hurt releases
. Although documentation was important,
for this release i would suffer with minimal
docs to get somethign out the door
.
Also, we DESPERATELY need debian
packages
and RPM (Red Hat Package Management) packages
to gain critical mass and get over the 'hard
to install' hump
. He would like to see seperate packages for
Forms, Application Server, Common and Reports at first, possibly with
seperate GNUe Common packages for each supported database later.
There were no technical issues with making debian packages -
i need to lock andrew, jeff and nick in a
room with some caffiene and computers and not let them out until its
packaged :)
.
Marcos Dione (StyXman) suggested a patch to add a textbox
widget to GNUe Forms. Jason Cater (jcater) said he would be worried with
the direction this is heading
if the
intention was to display html markup
.
After clarification, Jason confirmed that the existing text widget
could be made into a text box - set the
height="5" - and you get a 5-line text widget
.
Derek Neighbors (dneighbo) volunteered to do some testing of the GNUe
Application Server (GEAS). Jan Ischebeck (siesel) said
if the installer is working
without problems, we can do a release of appserver 0.0.1 soon.
Derek said not really as it relies on common -
or at least it should require common - which means we have to have a
release of common in conjunction with it
. Jan clarified
soon = after the release of common. :)
Derek tried playing stupid user
and tried to install using the instructions in the INSTALL.cvs file. He asked
does your setup.py in appserver directory
check for a VALID rpc driver installed?
Jan confirmed this.
Derek asked if you run appserver and no rpc
driver is available what happens? do you get a good error message telling
you wehre to get it?
Jan said this was the same as trying to use
an unavailable database driver - it raises an
error with an url
of the location of the driver. Derek liked
this idea.
Derek noted that the install file
did not mention the changes needed to the connections.conf file to define
a connection for GEAS. He got the various GEAS tests working on his system,
with just a few minor problems that had already been fixed since the
CVS snapshots had been run at midnight (Central Standard Time). He
wondered how it managed to access postgres
w/o me giving some sort of credentials
? Jan said
its reinhard's code. It just takes your
LOGNAME and set a bogus password.
Derek said, based on his
testing, i give it a green light
success
- it might make sense to release this as
Application Server 0.0.1 along with the 0.2.0 Forms/Designer/Common
releases. Daniel Baumann (chillywilly) did a round of
hi fives
for the GEAS team,
and added wait until it does cool
things like objects ;)
.
There was some discussion about adding support for
GConditions before the 0.0.1 release. Derek re-emphasised his
point from
imho, we
need a damn good reason to branch cvs and then remerge - 'cause
despite what anyone says, that's a bitch to manage :)
Derek said it was more a case of making
changes twice
. He was open
to suggestions, but the overall GNUe project was beginning to
get too big - too many developers -
too many itches - too many products
- to manage on the
informal basis that had worked fine until now. He said
some of it is we need good packaging
and testers - so we can better automate the release process - so
developers dont have to devote a week to 'releasing' - as that
would help a lot of the problems
.