Michael Dean (mdean) said that a new release
(feature wise) is probably about 3 or 4 weeks away,
since the
database upgrade was going to be huge. As of this writing, he may make an
interim bug fix/small feature release to get some of the email support
down.
Daniel Baumann (chillywilly) pointed out that
this abstraction thingy GComm
could be
confused with the GNU Comm project. But as far as Jason Cater (jcater) was
concerned, GComm is our internal package name...
to the external world, it's GNUe Common,
but said that was a good
point. Later, Derek Neighbors (dneighbo) explained that pyro was an object
system like GComm would be, written by the same
guys that wrote pygmy, the python email client.
Charles Rouzer (Mr_You) needed a production
quality GNUe web shopping cart ;-)
. Instead, he was looking to
customize Interchange to provide a web shopping cart using PHP. Jason Cater
(jcater) said that, although GNUe Inventory was not yet completed, you should be
able to access another inventory package via GNUe Applications Server.
However, the web interface for GNUe Forms was still in the works, as
Michael Maluck (madlocke) had been quite ill.
Four days later, Charles asked if anyone had seen Michael Maluck
(madlocke). Daniel Baumann (chillywilly) wanted to know
did he ever give up the code for this web forms
stuff? Or it still a mystical imaginary animal?
Derek Neighbors (dneighbo) was seeing a GREAT
value in DCL as a communication tool to customers,
and as a billing tool and todo tool. But the communication tool would break
when accounts had different products. It would be fairly easy to implement
who-can-view-what by product, but then the next step would become billing (or
services), at which point products and services would need to be 'separate'. This
hadn't mattered before DCL was seen as a communications tool. Michael Dean (mdean)
thought this use of services sounds like it could be an
action.
He planned to be work on it (minus
billing) for work, so it will come.
Derek Neighbors (dneighbo) had written a contact
manager to do assignments
for GNUe; and Jason Cater had a fully functional
40 node call centre. The call centre was not using Bayonne, although they would
like to. Derek reckoned GNUe was about the best GPL-licensed system he had seen for
RAPID development of cross platform applications. There were about 5 active
developers, 10 more regular contributors, 30 people with assignments and several
hundred on the mailing lists. There was no date for GNUe Accounting, but work was
starting on it now.
It was asked if GNUe Application Server (GEAS) uses database triggers or did
triggers itself. Derek Neighbors (dneighbo) said it
could really do either.
They were also looking to support
load balancing and replication in GEAS. But if your database supported it,
you could have load balancing occuring behind GEAS. But several people
thought that load balancing with GEAS could be complicated.
Daniel Baumann (chillywilly) confirmed that GNUe needs Python 2 -
er, the python stuff does anyway.
The next day, Andrew Mitchell (ajmitch) asked if GNUe stuff
works on GNU/Hurd.
Jeff Bailey (jbailey)
said GNU/Hurd did not have Python 2 as of time of writing.
Derek Neighbors (dneighbo) claimed GNUe Applications Server (GEAS) is Windows
ready, but depends on orbit
which didn't
do Windows well - he wanted to move to omniORB. Jason Cater was feverishly
working on gcomm, an RPC abstraction mechanism that would give lots of
flexibility.
Two days later,, Jeff Bailey (jbailey) noted that GEAS
doesn't seem to compile under windows because of the
orbit dependancy.
He asked if there was a timeframe for fixing that.
Daniel Baumann (chillywilly) said no. Jeff said this meant he couldn't make
GEAS part of the win32 package. Daniel said that
GEAS only runs on GNU/Linux and *BSD
-
and mac os X
, interjected Neil Tiffin (neilt). Daniel said that
porting GEAS to windows is not a priority
right now.
However, gobject and
orbit2 are both thread safe now and pretty functional
.
Reinhard Müller (reinhard) had compiled orbit under Windows,
but never run any program
Vsevolod Lobko (sevik) asked does
anybody have working gnuef+geas setup ?
Dmitry Sorokin
(ra3vat) said that he had some problems after re-installing and had
not tested it for a while. They discussed this further in Russian.
Later on, Charles Rouzer (Mr_You) said it was currently alpha,
hang out here and help us out and we'll
help you out ;-)
Vsevolod said that in
methods like next_record/etc there are print 'something' instead of
actual code
.
The next day, Vsevolod asked Reinhard Müller (reinhard) what the
current state of the driver was. Reinhard said that James Thompson had
started it, but has been mad goat
raped in the middle of the development process
.
Vsevolod asked if it had ever worked. Reinhard said:
Well parts of it worked in the past and I think they still work which means gnuef can get data from geas and write data back to geas but you cannot yet use the methods and some other things. You can use geas just like a normal relational db and you lose all the advantages of objects.
Vsevolod confirmed it does not work now
Even retrieving of data from geas
.
Reinhard said he was the maintainer of GEAS, but that he had not
had time to look at it for 2 months now due to job overload.
Reinhard Müller (reinhard) suggested taking out the PUBLIC and PRIVATE
keywords as we have no real use for them now -
or we will end up with a lot of
non-implemented keywords just like before
. Neil Tiffin (neilt)
agreed to taking everything out that
is not fully implemented, unless it will be implemented in the
next few tasks we are working on
. Reinhard asked if
this applied to READONLY as well. Neil replied that he was
not sure. Reinhard will investigate what READONLY does now.
Reinhard Müller (reinhard) asked about
the current syntax for explicit
reference
. Explicit references
were needed, but neither Reinhard or Neil Tiffin (neilt) were happy with the
current syntax for them. Reinhard proposed a
changed REFERENCE syntax in gcd:
REFERENCE refname WHERE thisfield [=<>!] otherclass.otherfield;
Neil said this needed to work for lists as well -
and a reference is just a list
with one entry
. Reinhard suggested, Actually
both could be combined by a sorta RELATION keyword
which is [...] n : m where n and m can be 1 or more than 1.
For implicit we still need both * and [] but for explicit I
think we could replace both REFERENCE and LIST with RELATION.
Reinhard Müller (reinhard) asked Shall
we keep andrewm's profiling code, or shall we remove it?
Daniel Baumann (chillywilly) and Neil Tiffin (neilt) both thought it was
unnecessary. Neil suggested contacting Andrew to see
why he did that - there must have been a reason.
Daniel said he
would ask some hurd hackers
for further
pointers.
Later on, Reinhard suggested using gprof, which
gives you statistics about time spent
in each function as well as number of calls for each function sorted
by the worst functions first (those eating most time) and lots of
other stuff. Plus you can break it down to lines of code instead of
functions. The only thing is it only measures cpu time
not the time the process waits for disk access or network traffic
.
By contrast, Andrew's profiling
code measures the RealWorld(tm) time spent in a function [...] which
is a very inaccurate thing in a multi process
operating system
. However, Reinhard would not
remove the profiling stuff without Neil's feedback.