GNUe Traffic #40 For 3 Aug 2002

                               By Peter Sullivan

An endorsement (I think) - "python might be crap, but we consider it a polished
 turd - not diarreha like java ;) - or bloated gas cramps like C# (i.e. a crap
                              waiting to happen)"

Table Of Contents

  * Standard Format
  * Text Format
  * XML Source
  * Introduction
  * Threads Covered

    1.  24 Jul 2002                xml2sql utility and .gsd (GNUe Schema
                                   Definitions)
    2.  24 Jul 2002                GNU Enterprise's influence on other projects
    3.  24 Jul 2002                CVS access issues
    4.  24 Jul 2002 - 25 Jul 2002  Using the DCL e-mail gateway to accept
                                   tickets from other applications
    5.  25 Jul 2002                Using CVS or official releases on Microsoft
                                   Windows
    6.  25 Jul 2002 - 28 Jul 2002  Primary keys in Forms and hand-editing GNUe
                                   Form Definitions (.gfd)
    7.  26 Jul 2002                Application Server planning
    8.  26 Jul 2002 - 28 Jul 2002  Visual Schema plug-in for Designer
    9.  29 Jul 2002                Application Server API and multi-language
                                   support
    10. 29 Jul 2002                Contact Management and extreme database
                                   normalisation
    11. 29 Jul 2002                Navigator search path for Forms
    12. 29 Jul 2002                GNU Enterprise tools as an alternative
                                   application development environment to PHP
    13. 29 Jul 2002                Status of GNUe Applications
    14. 30 Jul 2002                Config for encoding in Reports and Forms
    15. 30 Jul 2002                Walk-through on installing and running GNU
                                   Enterprise
    16. 30 Jul 2002                Preparing for Linux World Expo in San
                                   Fransisco

Introduction

This Cousin covers the three main mailing lists for the GNU Enterprise project,
gnue (http://mail.gnu.org/mailman/listinfo/gnue) , gnue-dev (http://
mail.gnu.org/mailman/listinfo/gnue-dev) and gnue-announce (http://mail.gnu.org/
mailman/listinfo/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 (http://www.gnuenterprise.org/irc-logs/) . For more information
about the GNU Enterprise project, see their home page at http://
www.gnuenterprise.org (http://www.gnuenterprise.org) .

1. xml2sql utility and .gsd (GNUe Schema Definitions)

24 Jul 2002 Archive Link: "[IRC] 25 Jul 2002"

Topics: Common, Designer

People: Ariel Cal?, Jason Cater, Jay Felice, Derek Neighbors, Jan Ischebeck

Further to Issue #39, Section #11  (22 Jul 2002: Using schema creation tools to
set up GNUe Applications) , Ariel Cal? (ariel_) noted "the syntax for foreign
keys that you and jan are definining is not what the xsl's are expecting" .
Jason Cater (jcater) said he "has not defined any foreign keys - that whole
thing needs to be discussed - as jan is doing a lot of stuff in there" . Ariel
asked "so it is better that i speak to jan" ? Jason said "well - that wasn't my
point - but sure" .

Later, Jay Felice (Eraserhd) asked "Anyone with authority on xml2sql, .gsd in
here?" He was "not using gnue or working on it, but in the spirit of not
inventing wheels, would like to use xml2sql." Jason said "xml2sql is really in
the early stages - I don't think we are satisfied with its current state" .
Derek Neighbors (dneighbo) said "the idea of xml2sql is it will be part of
common - any product with a gpl compatiable license may use it. I dont
necessarily seeing us packaging it outside common - as ultimately in will be a
tool too small in the toolbox of GNUe to segregrate out. I think the idea is
that integrator and designer will provide solid interfaces to it" . He asked
that "before more changes are made to .gsd that they be documented and sent to
dev list" to keep everyone involved and up-to-date.

Jay said he "would like to collect multiple schemas into a composite schema."
Derek said "im thinking you do this with includes" . Jay said "the includes
could conceivably overlap, so the "combinator" would have to be smarter" - "I
need a schema to be able to add a field. ... or one row, or a table, or an
index." . Derek invisioned "we would provide update schemas" as an alternative
to the full scheme for new installs, addoing "we will have similar issues for
'package' management. Another idea i had was a schema 'diff' program or updater
so to speak - so if you have an existing schema/database and you want want it
to now look like schema X you could run this compare/diff utility and it would
create the schema necessary to do the updates" . Jay said this "is something
that I very much need. I wrote a dbdiff utility a long time ago, but it only
works on PostgreSQL databases and has some flaws."

Derek suspected "the first phase will be providing tags that do alter/drop etc"
which would allow you to have seperate schema definition files for upgrade and
new install. "Its not great because you have to maintain a separate update file
by hand - but it provides upgrade mechanism - ultimately a program should be
able to do compare 1.0.gsd to 1.1.gsd" and work out the differeces for itself.
Jay felt, based on his experience writing his own dbdiff utility, that "there
is no way for the database to "know" how to upgrade data structure without
destroying data." Jan Ischebeck (siesel) said "you need a: GNUe schema
transformation hint file" . Jay suggested "The hints would have to be fairly
complex" and gave some examples. He did not think "there's a way around a
tested upgrade script" written by someone who understood the logic behind the
changes "but the diff utility (which prompts) is useful for developing on one
db and publishing to another."

Derek said he would expect to do an upgrade script from each previous version
to the next - if people skipped upgrades, they would need to "simply apply the
upgrades in succession" . Jay still was not sure "why would the upgrade be a
.gsd?" Derek said that, by adding alter/drop/add to the existing insert/create/
update syntax in GNUe Scheme Definition (.gsd) files, .gsds could support both
- but if it would "make everyone feel warm and fuzzy to have a .gud gnue update
defition and maintain yet ANOTHER .xsl file?" he would not object, although he
did not see any real need. Jay said "I'm thinking that how I plan to use this
is tainting the conversation... at this point, I don't care about db
independence for my project."

Derek said "to me that is only reason xml2sql is around (db independence)" -
and to provide "a quick migration path" for converting from, say, PostgreSQL to
SAP-DB. Although "postgres is a good little database" , he was increasingly
finding "it has friggin issues - not as many as mysql but still" , giving some
examples involving type casting - "which is fine if you only want to use
postgres - but if you are doing any kind of x DB stuff you are hosed as its so
non standard" . He felt that "from what i have seen of SAP-DB i think thats
where its at - especially because its supported on windows exponentially
better" . It was "GPL - so even a better license than postgres ;)" , with all
the tools released under either the GNU Public License (GPL) or Lesser GNU
Public License (LGPL). He had had a really good response from their developers
with queries, and "we have committment from the SAP-DB team to work with us on
any issues we find in the python driver for SAP-DB" . He felt "from what i have
seen SAP AG might be one of the few big boys that actually gets free software -
i.e. SAP-DB was not a money maker for them anymore (oracle and mssql and db2)
were always chosen instead - but they wanted to keep it for those customers who
do use it and believed in it - they figured making it GPL would help draw some
new blood outside SAP R/3 users" .

Jay explained what he would want to use xml2sql for - as a way of doing a
consolidated schema from a number of php files, each of which defined "it's own
"interface" to the database." Derek felt "this is outside scope of our toolset"
as "gsd is mainly way to get cross db definitions." xml2sql could be used to
produce .gsds "then write a program that uses an xml parser to aggregrate them"
but "that doesnt solve your issue" . Jan suggested "the merging of schemata s
hould be done with gnue-designer - its quite easy to add wizards" , now that
support had been added for plug-ins, as discussed in Issue #39, Section #7  (
18 Jul 2002: GNUe Designer plug-in support) , "so writing a "merge schema X
wizard" should be quite easy." . Even if the underlying application was in PHP,
that "doesn't mean that he cannot use a GNUe Development tool" .

For the .gsd format, Jan asked "any objection against <constraint name=
"fk_address_personid" type="foreignkey"><constraintfield name="personid"/>
<constraintref name="id" table="person"/></constraint> ?" Jay did not "like
uniqueKey/index/primaryKey, those should be the same, though. but all said, I
just care if it works." Jan said "I can understand why differentiating between
index and uniq index (=primary key), but doing 2 ways of specifying uniq keys
possibly makes programming a bit complicated :)" . Derek said "i need time to
look at what we have and where we are giong" but in principle "i like the idea
of <contraint with a type=" .

2. GNU Enterprise's influence on other projects

24 Jul 2002 Archive Link: "[IRC] 25 Jul 2002"

People: Marcos Dione, Jason Cater, Derek Neighbors

Marcos Dione (StyXman) asked a "python question: is there something like class
enums?" Jason Cater (jcater) said "no enums :( - my ONE gripe w/python" . Derek
Neighbors (dneighbo) thought "they had a clever work around to this" , and
suggested some web references. Jason said "yeah, but that stuff is a little
different" - as a workaround "it will suffice - but, bleh" . Derek said "it
will be interesting to hear what python 3.0 will hold" . Jason felt "it will be
interesting to see python after we become even more major - as zope had the
most influence on the development of 2.x" . Derek thought "gnue will be one of
python's glory projects soon - as well as wxWindows - we certainly abuse both
of them a lot" . Jason "REALLY hopes we can influence DB_SIG 3.0" . Derek
thought this was unlikely. However, Jason noted "read over the spec - DBSIG 2
is primarily for reading data i.e., non-transactional stuff - iow, DBSIG 2 was
written to create a standard so that Zope could get a lot of drivers so it is
really web-oriented" - GNUe really needed a more transaction-based approach to
the standard.

3. CVS access issues

24 Jul 2002 Archive Link: "[IRC] 25 Jul 2002"

People: Derek Neighbors, Marcos Dione

Derek Neighbors (dneighbo) noted that the changes made by Project papo staff
had been kept in their own CVS tree until now, but the Free Software Foundation
(FSF) had now received the postal copyright assignments, "so i think we are
probably ok to start taking patches from the papo pals ;)" . Marcos Dione
(StyXman) suggested "uh, we'll stick to our tree till everything's in place."
Derek was "more concerned that the longer it is the harder it will be to do" -
if he had known earlier that they were maintaining their own tree, then he
might "have told you we would take patches on good faith - to avoid having to
merge really stale trees together" . Marcos did not think there would be a
problem - "we're not puttin too much stuff in. at least, nothing that can clash
on your works..." Derek "just gets nervous that we will be playing the
reintroducing fixed bugs game i have seen in places ive worked" - he would
rather all patches were applied to the central CVS tree, especially as the
copyright assignment issues "i think will be resolved by weeks end" . For the
future, "im not sure best answer going forward - as there was thought of giong
to colonels like the linux kernel - i.e. limited cvs write access heads of
state - and way to do things is submit patches for review and then colonel
applies them if accepted. However there are many practical issues with that as
far as resources go" .

4. Using the DCL e-mail gateway to accept tickets from other applications

24 Jul 2002 - 25 Jul 2002 Archive Link: "[IRC] 25 Jul 2002"

Topics: DCL

People: Marc Lovelace, Jason Cater, Derek Neighbors

Marc Lovelace (AnZaC) said he was "lookin' to find a way to use an outside php
script to create trouble tickets through the DCL functionality.. that make
sense? As in, I'd like to be able to pass in all the information required to
the function.. and let DCL run with the ball..." Jason Cater (jcater) suggested
"look at the email gateway - it does just that - err, I mean as an example of
what to do" . Marc said he did not have root access, but Jason suggested "I
imagine you could set up a fetchmail script that runs like every 10 or so
minutes that fetches mail from an account and pipes it into dcl-gateway.pl -
that wouldn't require root access" . This would involve setting up a
.procmailrc and .forward file for the designated mail account. Marc thought
"that might just work" , asking "any way I can set up the .forward file to ONLY
forward email with XXXX in the subj?" Jason "thinks you'll need to use procmail
for that" , giving a sample procmail file. Marc "got qmail sending the email
over to procmail... got the .procmailrc filtering the mail as it comes in...
now I'm just trying to find where it put it.."

The next day (http://www.gnuenterprise.org/irc-logs/gnue-public.log.26Jul2002)
, Marc reported "got the gateway workin' somewhat w/o the MIME module..." Derek
Neighbors (dneighbo) said "i would still encourage getting them to let you
install the mime module" . Marc agreed, but asked "how I can get the BODY part
of the message w/o the module" , just in case? He noted "The rest of the script
works like a charm.. I'd just like to be able to have a little more information
inserted in the DB for the Issue Description..." Jason was "sure there are some
perl cpan modules you can grab that'll break apart the mime message" Marc said
he did not have install rights on the box he was using - if he had, he would
have installed the MIME module and solved the problem directly. Jason was "sure
you can install cpan modules locally" . Derek said they had tried this, but, as
Marc reported, it "gave me a root permissions problem" . Jason pointed to some
information on the web (http://www.rcbowen.com/imho/perl/modules.html) about
installing perl modules. Marc read the information and tried it out, but still
could not "install it into the perl directory" . He concluded that his "best
bet is to stand by and wait for the folks who own the box to give me a response
on installing the MIME parser..." .

5. Using CVS or official releases on Microsoft Windows

25 Jul 2002 Archive Link: "[IRC] 26 Jul 2002"

Topics: Designer, Application Server, Forms

People: Carl Kigundu, Andrew Mitchell, Ariel Cal?

Carl Kigundu (clock) said he wanted "to use gnue on windows 2000 with mysql" .
Andrew Mitchell (ajmitch) recommended "you should be fine with the 0.3.0
release - i've used gnue designer & forms on winXP with the mysql ODBC drivers
(mysql on a GNU/Linux box)" . For initial familiarisation, he would prefer the
0.3.0 release over CVS, as "i don't know how usable cvs is at the moment,
jcater has been working heavily on designer" , as referred to in Issue #38,
Section #5  (11 Jul 2002: Designer branched in CVS) . Alternatively, "you could
install both in separate paths & compare them if you wanted" .

Carl asked "now if my code is in the gfd does this mean each form will have to
open its connection to the db? isnt that expensive? anything I can do? wouldnt
i have to write a connection server or plug something into apperver to serve
requests?" Andrew said "only if you use appserver, i think" . Carl asked "i
thought i call the forms from withing the triggers of other forms?" Ariel Cal?
(ariel_) said "the issue of triggering other forms has been discussed" ,
pointing to Issue #34, Section #7  (12 Jun 2002: Opening one form from within
another) , saying "it is doable but not trivial right now" .

6. Primary keys in Forms and hand-editing GNUe Form Definitions (.gfd)

25 Jul 2002 - 28 Jul 2002 Archive Link: "[IRC] 26 Jul 2002"

Topics: Forms, Designer

People: Matthew Emmett, James Thompson, Jason Cater

Matthew Emmett (memmett) noted "when i was entering data into my "trip log"
form that had a master/detail relationship, the "detail" wasn't picking up the
new master id, so i had to continually press F8, F9, re-select the master i had
just inserted, then enter the data for the detail... is there some magical
thingy i'm missing? hmmm, i see some voodoo for "populating our primary key" in
one of the examples... perhaps this is what i need?" James Thompson (jamest)
confirmed "you'll have to use a trigger to pull the value - our backend doesn't
reload the record data after commit so the primary key remains blank :( - this
also causes issues with backend triggers altering data - the form doesn't
reflect it" . He gave "a working example" , but felt "we really need to handle
this better by default" . Matthew said "yeah that'd be nice. althought i guess
the trick finding a robust way to get the id of the record one just inserted.
MSAccess is totally broken in this regard, imo." Jason Cater (jcater) said
"designer now autocreates those triggers if you drag from the Schema navigator
- /me needs to update the Create new form wizard to do the same" .

Matthew said "ahh... well my luck with designer isn't so great, and editing the
xml by hand is just so much fun! :)" James said that "before jcater created
designer" , that had been the only way to do it, but "nobody liked hand editing
the gfd files :)" . Matthew said "heh.. yeah the only annoying part is having
to tweak the x's and y's. the great part about designer is that it produces
clean xml, so that one can easily use their favorite text editor to quickly
rename names="" or whatever." Jason said "that was a BIG requirement when I
wrote designer the XML had to be editable - a lot of that stemmed from the fact
that the first designer couldn't do much more than move stuff around" . James
said even then "it was still a god send for widget placement - now it's almost
a l33t development tool! ;)"

Some days later (http://www.gnuenterprise.org/irc-logs/
gnue-public.log.29Jul2002) , Matthew reported "when i switch to a new master
records (new as in, going to insert a new record) the detail remains as it was
before i switched to the new record. I think it causing problems when i press
F6" giving the log message. James explained "querys from a detail don't really
work" as of time of writing - "it should be generating a popup saying it's not
supported but it stopped doing that for some reason" .

7. Application Server planning

26 Jul 2002 Archive Link: "[IRC] 27 Jul 2002"

Topics: Application Server

People: Jan Ischebeck, Christian Selig

Jan Ischebeck (siesel) said he had written "some notes about transaction
support and locking. just need to add the stuff to _featuretest" This was, as
of time of writing, "on a good old piece of paper :)" but an earlier version
was at http://www.gnuenterprise.org/~jan/appserver/object_life_cicle.png (http:
//www.gnuenterprise.org/~jan/appserver/object_life_cicle.png) . Christian Selig
(sledge_) supposed "transactioning looks simpler that it is to code" . Jan
agreed, adding "writing transaction deadlock detection will be much more
difficult to do code than simple transactional locking :)" However, "there are
many other small steps to go: f.e. appserver should read out a configuration
file etc." Christian noted "since python 2.x, there is a module for that in the
standard distribution" .

8. Visual Schema plug-in for Designer

26 Jul 2002 - 28 Jul 2002 Archive Link: "[IRC] 27 Jul 2002"

Topics: Designer

People: Christian Selig, Jan Ischebeck, Derek Neighbors, Jason Cater

Christian Selig (sledge_) said he had "a very specific idea on how" the visual
schema Designer plug-in for GNUe Designer (as previously discussed in Issue #
39, Section #7  (18 Jul 2002: GNUe Designer plug-in support) ) "should look
like :)" . He suggested:

  * the order of fields should be draggable
  * a new field is created through that little "+"
  * connection of reference fields are created with d&d, the links are drawn
    automatically
  * tables should be freely positionable, positions should be saved

Jan agreed, but said "the last point is a bit problematic" as "I don't want to
store the positions in the gsd." Christian agreed "saving them in .gsd is not
nice, right." Jan said "that would mean, that you would need a seperate file
for every gsd" - or else "have a position cache which safes the positions for
the last 5 files" . Christian suggested "for the last "n" files, configurably
:)" Jan suspected that Christian "would set it to 9999 or something like that
:)" . Christian said "i don't know who told you rumors that i'd ever do that :)
" . Alternatively, the application could try "automatic positioning?" - Jan
suggested "depending on foreign key conections tables should be positioned in a
way make it easy to look at" .

Jason Cater (jcater) said he "didn't intend on the first version of schema
designer to be an ERD - /me was thinking ala access (grid table) - ERD to me
would be a secondary window" . Jan suggested "Why not use display modes, i.e.
you can switch between graphical or table view" ? Derek Neighbors (dneighbo)
asked "can we keep things simple re schema editor in designer - and have REAL
design sessions for the rest" . Jan was not keen on making it look too much
like Microsoft Access. Derek Neighbors (dneighbo) said "i am not a huge access
fan but in reality 90% of the business population uses access and knows how to
use it" - being able to say "if you can use access you wont be too lost in GNUe
Schema Editor" was "a HUGE factor" . However, "the goal of gnue is not access"
, and "there are so many other parts of GNUe that need attention it seems silly
to put too much effort early on into schema stuff - short of making it work" .
Jason said "to me, having tables with lines connecting them to show foreign
keys IS close enough to ERD to call it that" . He felt that a full graphical
canvas for tables was "overkill for the time being" .

Christian said "there are two modes: editing the tables in grids, and visual
display on a canvas - so, strategically, either visual display has to be left
out or done right" . Jason agreed - "for the time being" just a "table
designer" . Derek said he could "do some screen shots and such to better
facilitate the discussion" . Jason felt that ""done right" is highly subjective
- I threw away my ERD packages 3 years ago - because they are
counter-productive - and once you move beyond a few tables, totally useless
imho" although he "isn't arguing against such a tool in the future" . Christian
felt that "personally, even with large databases, a visual designer and, more
important, a way to print out the visual version :) is very helpful" . Jan
agreed "that its quite complicated to work visually with more than 20 tables" .

Jan posted a screenshot (http://ash.gnuenterprise.org/~jan/vschema_mod.png) of
what "a visual editor could look like" . Derek warned "wx has been well not
polite with drag/drop and mouse stuff - so it scares me to put too much effort
(i do want something like what you are pasting very badly) - but im going best
bang for buck to start with" . As of time of writing, "im concerned with BASIC
single table creation/modification - i.e. im not against what you are proposing
but i think its the 'second' step not the first one" . Initially he envisaged
something more like this (http://gnue.org/~dneighbo/viewer.jpg) .

Some days later (http://www.gnuenterprise.org/irc-logs/
gnue-public.log.29Jul2002) , Derek pointed to "a free tool (http://
squirrel-sql.sourceforge.net/index.php?page=screenshots.html) (nasty ole java)
that might be some inspiration for what you all would like to do with gnue
schema stuff - it is very similar to pgadmin" . Jan said "I think the main goal
of having a schema designer instead of f.e. pgaccess, is that you design a
schema which will work on all databases which are supported by GNUe. I.e. it
should be very easy to use, without providing too much db specific features
i.e. if you just use GNUe tools for developing and creating your application
you can move it from one type of database to another just with copying the data
from one db to another - this is possibly a bit too optimistic, but I would
like that :)" Both Jason and Derek felt this was an absolute requirement. Derek
said "i dont think there is a good 'python' (xplatform) tool out there that we
could just bolt on support for our schema stuff - or i would say lets go that
route. I see GNUe as a real framework in that it shouldnt be a replacement to
hardcore db management tools but certainly developers should be able to use the
framework (so they dont have to learn something new and/or install more crap).
I like it from the prospective of it should really help us a. increase power of
python DBSIG b. increase functionality of our common dbdriver system :) - maybe
someday Zope or such might even consider using it :)"

9. Application Server API and multi-language support

29 Jul 2002 Archive Link: "[IRC] 30 Jul 2002"

Topics: Application Server

People: Jan Ischebeck, Andrew Mitchell, Dan Kuykendall

Jan Ischebeck (sisel) said "it is important to split the API in different
implementation levels:"

  * level 1: no object, just remote method execution (should be able to
    implement in all languages)
  * level 2: object support via proxy objects, but proxy objects just contain
    an execute("name","params") method and a "get" "set" method
  * level 3: object support via fully transparent proxy objects, which catch
    all executed methods and send it over to the remote object (in python:
    using __call__)

Andrew Mitchell (ajmitch) said "we should define remote calls to other
implementations, for getting lists of methods, etc - since this should be able
to work over multiple transports" . Jan agreed - "this would be a kind of
introspection function which should be added to the API" . Andrew said that,
with some thought, this could be done in most languages - "for C# i'll probably
need to build proxy objects using Reflection.Emit, which outputs IL (sort of
like meta-assembly)" - "with php - generate code & cache it" . "however for
GNUe, since we have the beautiful python to use, it's much much simpler ;)" .
For php (especially php GroupWare), Andrew said that Dan Kuykendall (Seek3r)
had hinted that once version 1.0 was stabilised, "a more structured project
will be born that makes the phpgwapi more accessible - apps will be composed of
a backend & a frontend UI - so GNUe will be able to talk to the apps quite
nicely" . Jan said he had "talked a bit about defining object types with
seek3r."

10. Contact Management and extreme database normalisation

29 Jul 2002 Archive Link: "[IRC] 30 Jul 2002"

Topics: Forms, Customer Relations

People: Jan Ischebeck, James Thompson, Derek Neighbors

Jan Ischebeck (siesel) asked about "the status of that forms/samples/track/
forms/contact_manager.gfd form?" James Thompson (jamest) said "that's a derek
form that was created long ago - i think it still works but IIRC the
pre-existing data model he had to wrap around was fugly" . Jan said "some parts
are quite usable, but I can't test it, because the triggers are broken." It
seemed to be using some old-style code, including using triggers to do
nextRecord(). James said these were now done within the block rather than via
triggers. The problem with the contact manager form was "IIRC that data was
hyper-normalized just like you're taught in class - which doesn't work in the
real world in most cases IMHO :)" and in this case had meant having to use a
specially-written trigger to check data integrity before calling nextRecord().

Jan asked "jamest: at the moment GFBlock just expose gotoRecord, newRecord and
clear, do you think that adding nextRecord, prevRecord, deleteRecord would
break anything?" James said "it shouldn't as long as you use the arrays in
there to extend the trigger namespace" .

Later, Derek Neighbors (dneighbo) noted "before you do too much work i had (as
of a month ago a WORKING contact_manager.gfd file) just not in GNUe :) for some
fsf stuff" . He tried to get access to it, but did not have all his ssh keys
set up properly. He eventually found "a more up to date contact manager (http:/
/gnuenterprise.org/~dneighbo/contacts.tar.gz) " file he had written - "im
pretty sure a month or so ago it was working (er around 0.3.0) - i could swear
the next/prev was working thne. I hope to work on this some tonight and then
merge changes softly back into the samples directory" . Now that he had "got
the LIST of copyright from youmans i will add the 'assignment' status back in"
to the sample database, and also set this up for his own use to keep track of
FSF copyright assignments for the GNUe project.

11. Navigator search path for Forms

29 Jul 2002 Archive Link: "[IRC] 30 Jul 2002"

Topics: Navigator, Forms

People: Andrew Mitchell, Jan Ischebeck, James Thompson

Andrew Mitchell (ajmitch) reported "i can open forms in the current dir with
navigator if i do "./form.gfd" but not "form.gfd"" . Jan Ischebeck (siesel)
said "if there is no ./ before form.gfd it looks for that file in ~/gnue/forms
- there should be a setting for that in gnue.conf - but I think we should
change it to search in local dir AND default forms path" . James agreed - "I
could test new forms in the std navigator menu by just cd'ing to dir holding
new forms and running std navigator" . Andrew changed the code and submitted it
as a patch.

12. GNU Enterprise tools as an alternative application development environment
to PHP

29 Jul 2002 Archive Link: "[IRC] 30 Jul 2002"

Topics: Why GNUe?, Financials (Accounting)

People: Jose Javier, James Thompson

Jose Javier (josejavier) asked "i'm looking for a tool to make programs like
accounting software, my question is, is gnuenterprise manure enough to do this
kind of programs?" He quickly changed "manure=mature" but James Thompson
(jamest) thought "you had it right the first time ;-)" He said "gnue could do
accounting but it's very much a work in progress - i'd love to see you work
with it but I don't want to give impression it'll be easy at this time - i'm
sure you'll find things that are missing, need improved, etc, etc" . Jose said
"i think this is a very interesting project, an i would like to contribute" He
had been considering using PHP for his next major project "but gnuenterprise
looks more interesting" .

13. Status of GNUe Applications

29 Jul 2002 Archive Link: "[IRC] 30 Jul 2002"

Topics: Application Server, DCL, Financials (Accounting), Bayonne, Forms,
Reports

People: Reinhard M?ller, Derek Neighbors

Reinhard M?ller (reinhard) said that "the actual packages are _way_ too early
in development - what is quite usable now is the tools like forms, reports etc.
however appserver is still at the very beginning of development - and the
packages would heavily depend on a working appserver :)" . Derek Neighbors
(dneighbo) said "we have three 'applications' that are somewhat functional that
are getting converted to the framework" :

  * DCL - Project Management / Bug Tracking
  * NOLA - Accounting (Small Business ERP)
  * Bayonne - Telephony Application Server (actual tool of )

He clarified that NOLA was not actually part of GNUe, but "the GNUe team is
porting NOLA to the GNUe Framework" and improving it - "then we will add GNUe
Forms Screens for it - we are offerring the (somewhat massive changes back to
noguska) - if they accept them (they seem willing at this point) it will be
normal NOLA - other wise we will fork" .

He also noted that Application Server "works with forms now - its just not
'mature' - and the 'business logic' side of the fence probably is very immature
but its being actively worked on by siesle and sledge (iirc)" . However, "im
about to beat jcater up for some gruesome report loving soon and that will
probably spur appserver development" .

14. Config for encoding in Reports and Forms

30 Jul 2002 Archive Link: "[IRC] 31 Jul 2002"

Topics: Reports, Forms, Common

People: Ariel Cal?, Arturas Kriukovas, Jan Ischebeck, James Thompson

Ariel Cal? said that he had "a problem with the patch you introduced in
GParser.py (encoding) - grcvs does'nt run if the encoding variable is not in
gnue. conf. Either: 1)give it a default value, 2) check if it is defined in
gnue.conf, if not call in line 220 as pre-patch" . Arturas Kriukovas (Arturas)
said that "when i first introduced 'formFontEncoding' in gnue.conf i also
introduced default value - going to check it..." He confirmed "it has default
value already (it is there more than for a month if i'm not mistakening) called
formFontEncoding - default value should be iso8859-1" . Ariel said he was
having problems with this in Reports. Jan Ischebeck (siesel) noted that it
"seems like formFontEncoding is defined in section forms, but not defined in
section reports - if you start up reports it uses "section reports" as default
section, i.e. you can't access formFontEncoding (see: GConfig.py)" . Arturas
suggested "would it be good if i add check whether encoding is set - and if not
would set it to 'iso8859-1'?" . Jan suggested "a much cleaner solution would to
add a [gnue] section to the config file" . James Thompson (jamest) agreed - "i
think I started work on this but didn't finish" . He "was wanting a global
[gnue] section that std gconfig reads first then merges in the specific [forms]
[reports] etc - so that a person could override specific global settings in
certain apps" . In terms of the code base, "I'd think it should be moved into a
generic one in common - i _think_" . Ariel suggested that "[common] is a better
name than [gnue]" .

15. Walk-through on installing and running GNU Enterprise

30 Jul 2002 Archive Link: "[IRC] 31 Jul 2002"

Topics: Forms

People: Stuart Bain, Derek Neighbors

Stuart Bain (stbain) said "I'm on a RHL7.3 box now, what do I need to get up
and running w/ the latest and greatest?" Derek Neighbors (dneighbo) said that
"the major components are python 2.x (preferably 2.1), wxPython and a database
(Postgres, MySQL, SAP-DB). Most of the other dependencies have started to go
away. If you want to do reports you will probably want to pick up Sablotron and
PySablot. Oh and you will need the python driver for whichever db you choose. I
like to get wx and python first to verify a normal form works - then grab db
set it up - then get its driver test a db form - then move on to swearing at
reports :)"

Stuart confirmed "I have wxPython RPM installed - should I grab the CVS
snapshot?" Derek said yes - "un tar it somewhere - then in gnue/ run
setup-cvs.py and answer questions to your liking (i pretty much just hit enter
(i.e. take defaults)) but certainly you can do as you like - the defaults put
everything in your home dir (which makes nice for clean up later)) or running
cvs in conjunction with stable" .

Stuart set up postgres, and Derek suggesed "go to gnue/forms/samples/intro/ and
run the intro.gfd" . Stuart reported an error - "This GNUe tool requires
mxDateTime to be installed" . Derek said "grrrr - i forgot about that" . Stuart
confirmed the error message suggested an URL to collect the dependency, which
he installed and reported "intro form is up and running" . Derek asked "do you
have postgres running? if so do you ahve an databases? if so do you ahve any
tables in the database if so do they have any data :) and do you have a
postgres python driver" ? Sturt said he had the
"postgresql-python-7.2.1-5.i386.rpm" driver. Derek said that Stuart would have
to edit his connections.conf file to alter the gnue database connection from
psycopg to postgresql - "then go to gnue/forms/samples/zipcode/ - do a psql
gnue then inside psql do \i pg_zip_code.sql " . He added "after that loads do a
~/bin/gfcvs zipcode.gfd and see if things work" . He confirmed Stuart would
have to set a user up within postgresql.

Stuart did this, but got a message "Error: Driver not installed: pygresql for
PostgreSQL [No module named pgdb] - I must have missed something somwhere" .
After some digging, Stuart checked "if the postgresql-python RPM has the files
we're looking for" . Derek warned "on redhat they have 1.5 and 2.x" versions of
python. Stuart confirmed this was the problem - "postgresql-python - /usr/lib/
python1.5/site-packages/pgdb.py" . He had had similar problems with Red Hat
before - "apparently they haven't noticed that the rest of the world is moving
on without python 1.5.2" . He found "postgresql-python-7.2.1-14.i386.rpm" -
"after a --nodeps install - it works - prompts me for a login - then promptly
crashes" . Derek said "rerun it - i think some 'themes' dont play nicely - i.e.
i have seen this on mor ethan on occasion - and simply relaunching makes
problem go away" .

Stuart confirmed "ok... now I have a bunch of blank fields - city, state, zip"
. Derek suggested "hit the prepare query button on tool bar then hit execute
query button - or use the function keys or menus" . Nothing was coming up in
the zip code form, so Derek suggested "ok shut it down and run states.gfd
instead - then on login run f8/f9" . Stuart reported "I have a list of hte
states - the states were populated in the zipcodes.gfd dropdown selection box
as well" . Derek confirmed "if you are getting data loaded when you run
states.gfd - then you are workign :) - you have a workign GNUe System - /me
runs before you try to really use it and ask real hard questions" .

Stuart asked "ok - so where do I download accessmdb2gnuegfd - lol" . Derek said
"in all seriousness - go to pgadmin.postgresql.org - download that application
(runs only on windows) and download the access migration tool - this tool will
provide mechanism to convert all tables/indexes/keys etc from access into
postgres which is half the battle. At which point with some effort you could
then rebind their existing access screens/forms to use postgres tables - then
you start on the conversion of access forms to gnue forms :) We have no
'direct' migration tool for that part, but it should be fairly easy using our
'wizards' in designer since the 'structures' exist" .

16. Preparing for Linux World Expo in San Fransisco

30 Jul 2002 Archive Link: "[IRC] 31 Jul 2002"

People: Derek Neighbors, Jason Cater, David Sugar

Derek Neighbors (dneighbo) asked "how are the marketing items coming /me is
hoping we will have somethign by friday?" Jason Cater said "/me will try to
show you what I have tonight" . Derek said he was not heading off to Linux
World Expo early, "just next week will be hectic so im hoping that this weekend
or monday maybe can get stuff to printer (or if you are printing suppose it
doesnt matter as long as it drops before next friday) :)" Jason said it "may
work better for me" for him to print them and ship direct to San Fransisco.
Derek said "i just have very little left of old stuff so will need something
for the show and would rather not make copies of what we had :) i.e. we need
more effective marketing. I also need to get our sample applications and such
up and running on my laptop. I want to demonstrate schema stuff as well i.e.
create a db schema - push button and now its mysql and postgres. I also want to
get sapdb installed and functioning well. /me pulls hair out, so much to do so
little time" .

Later, Derek asked David Sugar (dyfet) about demonstrating "gnucomm/bayonne in
gnue booth - i would love to get some stuff working - you have any samples that
write to a database? preferablly postgres" . David said he did not "know what
type of demo rich had in mind to setup." Derek said he would "love to make some
forms to interact with it - to show not so much 'integration' but combination"
. David agreed - "In fact, I want to do a model gnu enterprise "debit calling"
system with the debit card accounts managed thru gnue forms."

 

 

 

 

 

 

                                Sharon And Joy
                                        

Kernel Traffic is grateful to be developed on a computer donated by Professor
Greg Benson and Professor Allan Cruse in the Department of Computer Science at
the University of San Francisco. This is the same department that invented
FlashMob Computing. Kernel Traffic is hosted by the generous folks at
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License version 2.0.