Kernel Traffic
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

GNUe Traffic #61 For 28�Dec�2002

Editor: Peter Sullivan

By Peter Sullivan

Happy Holidays from Kernel Cousin GNUe!

Table Of Contents


This Cousin covers the three main mailing lists for the GNU Enterprise project, plus the #gnuenterprise IRC channel. Kernel Cousins GNUe is now group-authored: if you'd like to join the team, let us know.

1. 0.5.0 Pre-releases available

16�Dec�2002 (1 post) Archive Link: "[Gnue-announce] Pre-releases for 0.5.0 available for testing"

Summary By Peter Sullivan

People: Jason Cater

Jason Cater announced "Very soon, we will have a 0.5.0 release for Forms and Designer, as well as a minor 0.4.4 release for Common. Before the final release, we encourage everyone to test the new prereleases" , which were available on the website. He noted "Please note that the 0.5.0 Forms file format (.gfd) is not compatable with the previous versions. However, there is a utility in the Forms tarball -- utils/ -- that can convert an older form to the new version."

2. Interbase/Firebird driver in Common

18�Dec�2002�Archive Link: "[IRC] 19 Dec 2002"

Summary By Peter Sullivan

Topics: Common

People: Dmitry Sorokin,�Bajusz Tam�s,�ra3vat

Dmitry Sorokin (ra3vat) asked whether the drivers for Interbase or its free fork Firebird were "included in binary build" for the Windows setup.exe version of the GNUe Tools. Bajusz Tam�s (btami) confimed this, adding "if you want to use interbase/firebird - i'm suggesting to wisit too" . Dmitry had a friend who was having problems trying to connect to Interbase, getting an error message "-901 Unable to determine field precision from system tables: Attempt to execute an unprepered dynamic SQL statement.." . He asked "does introspection work" ? Bajusz said it was working for him - "i made a country.gfd with designer's wizard then run it without any error with 0.4.3 exe's and firebird 1.0 - which versions you use ?"

3. Using GNUe Common in other projects

19�Dec�2002�Archive Link: "[IRC] 20 Dec 2002"

Summary By Peter Sullivan

Topics: Common

People: James Thompson,�Jason Cater,�Jeff Bailey,�Derek Neighbors

James Thompson (jamest) "just did a line count check of .py files in gnue - 89981 total" - "pressing all those returns in the middle of each file really help get our counts up didn't it :) - or course after the 0.6.0 cleanup will probably have about 1500" . Jason Cater (jcater) suggested removing comments from the count somehow - "but that assumes we add comments to our code ;)" . James did a full analysis using SLOCcount, reporting the results as:

SLOC Directory SLOC-by-Language (Sorted)
16937 common python=16486,sh=390,php=61
8928 designer python=8889,sh=39
6138 forms python=6099,sh=39
4193 appserver python=4140,sh=53
4127 reports python=4053,sh=42,perl=32
2537 phpforms php=2537
1005 navigator python=984,sh=21
921 top_dir python=921
431 integrator python=410,sh=21
34 packages python=34
0 docbook (none)
0 CVS (none)
0 samples (none)

Later, Jason noted "shows the power of common, doesn't it? or at least significance" . James said he was "i'm using common outside of gnue a lot now" - "any python program I do is based upon common" . Jeff Bailey (jbailey) said "I don't really know what common offers aside from database abstrction" . Derek said it was much more than that - "in the sense it handles master detail and such" . It was similar to proprietary tools like BDE (Borland Database Engine) and VCL (Visual Component Library). James said just about the only bit of Common he did not use was the database abstraction, as "it does'nt work w/o major effort outside GNUe" . However, "basing my apps on GClientApp gives me a logging system GDebug that features output redirection to a file - good for non interactive apps - a command line parsing system that is rather feature complete and easy to use - built in profiling engine - a configuration system, it's a trival matter to add .ini config suport to a GClientApp - and that allows automatically a "pine" style config with system settings, user overrides, and system fixed (non overridable) settings - this is stuff almost all my apps use" . Jason also mentioned the man page generation and the "command-line debugger" .

Jason also noted "common has a strong DOM-style XML parser library - that I use in some of my stuff - as well as db abstraction - and the start of client-server abstraction i.e., base your code on and you get cross-platform daemon initing plus rpc abstraction - /me hasn't used the daemon-mode stuff outside of gnue yet" . Also "we have a wicked curses library - called cursing - that is really shaping up" . Jeff asked how the DOM library worked. Jason explained "it's a DOM-like model - not a DOM implementation" - "it's more an XML-To-Object and Object-To-XML library" . James added "and when using it you also gain a trigger system - so that it was fairly simple to add triggers defined in xml to your objects. The forms, reports triggers are based upon this code. It exports named objects into the trigger namespace automatically." Jason said "what is really cool is that it's an Object marshalling system that currently has an XML mode - there's nothing stopping someone from writing an Object-to-SQL and SQL-to-Object layer - to store objects (forms, reports, etc) in a database - that has been discussed before" . James concluded "I may be biased but common rocks my socks" .

4. Trying to delete non-existant AppServer Objects

19�Dec�2002�Archive Link: "[IRC] 20 Dec 2002"

Summary By Peter Sullivan

Topics: Application Server

People: Jan Ischebeck,�Reinhard M�ller

Jan Ischebeck (siesel), having read Issue�#59, Section�#13� (8�Dec�2002:�Error handling in GNUe Application Server) , asked "about error handling of non existant object identifiers in appserver" . Reinhard M�ller (reinhard) said it had been agreed "that if in "store" multiple objects are stored with a single call - then a failed validation of a single object causes that none of the objects are stored, but an exception to be raised" The issue now was "if we call "remove" - and one of the objectid's to delete doesn't exist - will the rest of the objects be deleted, or will there be an exception an no deleting be done at all" ? Jan thought "store and delete should use the same mechanism. i.e. full ""rollback"" of action in case of error." Reinhard agreed - "calls to the "raw" interface should be atomic - that is all is done or nothing is done" .

Jan asked "how should the exeption be defined? It should return the OID of the invalid object. And what about multiple invalid objects in a store operation. Should only the first one be returned, or should all be returned" ? Reinhard thought "invalid objectid's probably indicate an error in the calling code don't they?" Jan agredd, but said that object calls could be invalid for reasons other than an invalid Object ID - "It could possibly be an object with an valid oid, but which don't fit some constraints" . Reinhard agreed, giving the classic example of trying to delete a customer that "still has open orders" . He "could imagine some system like "get_last_error" which returns a text like "Can't remove customer, because it still has open orders"" Jan suggested adding a "system table: session_errors - then you can get one error or many errors at one time, and you don't have to define new commands." Each "error would need the following informations defined: 1. the error text (like can't remove customer... 2. the involved object (stored as oid) - probably 3. a system interpretable status flag - probably 4. the involved table" .

Reinhard had "looked at the - do i interpret correctly that this is only a framework and the functions of the new api are not really implemented?" Jan said "they are partly implemented. geasSessionManager functions calling the appropriate session functions - geasSession functions calling the appropriate class functions - at the moment geasSession is finished and I'm just working at" . He had not "commited yet, because there's still to much subject to heavy changes in it." Reinhard took the hint, and said "I'll keep my fingers out of new API implementation" - instead "I might look at the "python object faker"" - officially known as the "language interface"

5. Record Caching in Common

20�Dec�2002�-�23�Dec�2002 (4 posts) Archive Link: "[Gnue-dev] Cache in Common"

Summary By Peter Sullivan

Topics: Common, Application Server

People: Jan Ischebeck,�Reinhard M�ller,�James Thompson,�Jason Cater,�Stan Klein

On r nothing is done.

Jan asked "how should the exeption be defined? It should return the OID of the invalid object. And what about multiple invalid objects in a store operation. Should only the first one be returned, or should all be returned" ? Reinhard thought "invalid objectid's probably indicate an error in the calling code don't they?" Jan agredd, but said that object calls could be invalid for reasons other than an invalid Object ID - "It could possibly be an object with an valid oid, but which don't fit some constraints" . Reinhard agreed, giving the classic example of trying to delete a customer that "still has open orders" . He "could imagine some system like "get_last_error" which ruote who="James Thompson">user says show me record 20000 - cache have to load and store all 20000 records. Instead of a sliding window that retains only "dirty" records we have the whole thing. I would love to see this work better - where you set a maxRecord in memory" .

It did not cache data between queries, but "it should be trivial to store the query as a key - along w/ the cache contents" . Reinhard M�ller (reinhard) felt that "caching in a multi-user environment is not a trivial task at all" . James agreed, also noting "coordinating this w/ 15 dbs of varying capabilities will not be fun" . Jan asked "there should always be the option to keep the cache very small, or even nonexistant" ? James said "if our sliding cache worked like i described above that would be a simple matter of <datasource ....... cache="1"> - the only issue being does the cache refuse to load the next record until everything in it is clean - or does it allow dirty records to accumulate to some fixed qty" ?

He added "there is a reason cache is now so stupid :) - basically time vs payoff at the time of implementation. What we have now devistates applicatoins like pgAccess - which forces all records to load on start - but it's far from complete" . Jan said "appserver now has a function fetch(list, start, count) to get a slice of a resultset" . James said "your fetch(list, start, count) is the sliding window I spoke of - if implemented properly appserver could use this via it's fetch - and an application like forms could use this as a sliding window over the data - to keep memory usage down" .

On the mailing lists, Jan summarised the IRC discussions, before highlighting the problem of "dirty" (modified) records in the cache. For simple record sets, the cache could simply write back the changes before moving onto the next cache set. However, where the changes were part of a multi-part transaction that was not yet completed, this was not allowed. He suggested a more complex caching mechanism to deal with all these posibilities. Jason Cater said "For the most part, what you describe has been our intention all along." He added "The current "keep all records in memory after they are loaded" solution was a stop-gap solution" . He felt "I would like to point out that the same is still true now that you are doing App Server. The caching doesn't have to work in its final form immediately." He suggested "we hold off on adding this functionality to common for the next release cycle or two." In any case, "I do not agree with limiting the maximum number of dirty records." James suggested to Jan "If you feel this is something important that is holder back appserver then I am ok with seeing it implemented at this time. I have some forms where this new cache would be nice. However I'm also concerned about common's database stability. Common itself has become fairly static over the last few releases" . If Jan was keen to do the cache enhancements, these could be done in CVS head, with the old version kept in the stable branch of CVS. "Since the changes will be transparent to the applicatoins it should be trival to switch between the two versions for testing purposes." .

Stan Klein warned that any GNUe cache had to recognise that there might be multiple other caching mechanisms in use - "The database systems have caches, the operating system and its device drivers provide caches, the devices themselves provide caches, and the processor chips have caches. In addition, the virtual memory systems commonly provided by operating systems are also a form of cache." Multiple caches could work together, but could sometimes get in each other's way. "GNUe is intended to run on multiple operating systems and to use multiple database systems" , which made this more dificult to avoid.

6. Security proposal now on webiste

21�Dec�2002 (1 post) Archive Link: "[Gnue-announce] Draft proposal for Security Framework"

Summary By Peter Sullivan

People: Peter Sullivan,�Stan Klein

Further to Issue�#59, Section�#4� (5�Dec�2002:�Security framework for GNUe) , Peter Sullivan announced that Stan Klein's "draft proposal for a security framework for GNU Enterprise has been added to the Documentation page of the website."

7. Getting text encoding for messages in

21�Dec�2002�Archive Link: "[IRC] 22 Dec 2002"

Summary By Peter Sullivan

Topics: Forms, Common

People: Dmitry Sorokin,�Jason Cater,�James Thompson,�ra3vat

Dmitry Sorokin (ra3vat) asked "i need to check gnue.conf/formFontEncoding in the beginning of, how to do that properly?" Jason Cater (jcater) said "if it's something that will be accessed in GBaseApp, we have to rename it to something besides formFontEncoding" , as this implied it was specific to Forms. Dmitry realised that the code was written the way it was because "gettext translation is initialized in the beginning of GBaseApp - before any other subsystems are initialized" . Jason said that, regardless of the renaming issue, there was a bigger issue, in that the code logically therefore needed to know which encoding had been specified in the gnue.conf configuration file before it had had a chance to load it! Dmitry wondered "may we initialize gettext later but before we output any messages ?" James Thompson (jamest) wondered "why is this happening before the config system is init'd?" - it "looks like it's only adding _ to the namespace of the app" . He then realised "in files like GFClient _ is used prior to it's _init_ even being called" . He suggested a possible workaround and noted "i was going to store string references to be process later - but that doesn't help the assignment of them" .

8. Dialog boxes in Forms returning parameters

22�Dec�2002�Archive Link: "[IRC] 23 Dec 2002"

Summary By Peter Sullivan

Topics: Forms

People: James Thompson,�Marcos Dione,�Derek Neighbors,�Jeff Bailey

James Thompson (jamest) was "still working on merging in some of" the code from Marcos Dione's (StyXman) patch. This patch aimed to re-merge the changes made by Project Papo for their version of GNUe into the main code base, as previously discussed in BROKEN KCREF. He explained "instead of the generic message box thing you created I'm implementing <dialog> instead" . Marcos said they had used the message box "mostly for showing things from triggers" . He asked "now that forms can call forms from triggers - is there any way to return things?" James said "probably via it parameters support" - "plus <dialog> will offer this - <dialog> is really just an alias for <form style="dialog">" . So "whatever parameters passed to a form are passed back at close IIRC - so if you mod them you'll see the changes" . Marcos noted that runform was not in 0.4.1. Derek Neighbors (derek) confirmed this "is fixed in 0.4.3" . As of time of writing, there were no Debian packages for the 0.4.3 release - "worse case you can get the 0.4.3 release or the 0.5.0 pre-release" as tarballs. Jeff Bailey (jbailey) said "I haven't done new uploads because I haven't had time to think about the bugs you posted, and because the 0.4.3 packages don't contain the man pages."

Later, James confirmed that <dialog> "will allow you to use any gnue form definition as a popup from another form" , returning values. "Once I'm done implementing some of forms current popups will be replaced with build in <dialogs> - like the jump to record dialog" and "lookup dialogs" . This would be included in the 0.5.x series of releases, but probably not 0.5.0 - although "i'm almost done with it - i plan to finish this week, the holidays willing" .

9. Project Papo 0.1.x releases

22�Dec�2002�Archive Link: "[IRC] 23 Dec 2002"

Summary By Peter Sullivan

People: Dmitry Sorokin,�Marcos Dione,�Jan Ischebeck,�ra3vat

Dmitry Sorokin (ra3vat) asked "how is papo doing?" Marcos Dione (StyXman) said "good, we've done a 0.1.0 release, and a week later the first bugfix. and we're installing it in some testing cases. people are calling in asking for it. we appeared in the local newspaper."

Later, Jan Ischebeck (siesel) said he had "had a look at Papo's savannah page. /me didn't know that version 0.1.1 is released already" . Marcos confirmed this - "and we set it up in some places around here for intensive testing." Jan asked "How feature complete is 0.1.0? Is it 50% of needed features already implemented? Or 20%?" Marcos said this "depends. if by 'of needed' mean all that was planned for december, it's 90% I guess. if you mean the whole system, I would say like 25/30% - but I can't guaranty that" .

10. HTML User Interface for Forms

23�Dec�2002�Archive Link: "[IRC] 24 Dec 2002"

Summary By Peter Sullivan

Topics: Forms

People: Jeff Bailey,�Charles Rouzer

Further to Issue�#60, Section�#6� (13�Dec�2002:�HTML User Interface for Forms) , Jeff Bailey (jbailey) said he had intended to work some more on the HTML interface "all of this week. I had forgotten about Christmas." It should be in CVS "Mid next week, probably,." "The initial checkin will probably be stubs, and then I'll implement all of the widgets. It should be really quick to do. The hard part will be the session handling and getting "gnue-forms" to act like a proper cgi-bin. Even session handling won't be too bad, though. Probably just use the databsae login name and password and rely on the web server to SSL everything and all that." By "proper cgi-bin," he meant "It would need to handle all of the environment variables and everything to pull inthe information. Right now none of that machinery exists." Charles Rouzer (Mr_You) asked "isn't there a CGI library builtin to the core python distro?" Jeff thought "Probably. But how to best plug in into forms? It would be best to use a helper library." Charles suggested "generally all you need to do is make sure every output screen has: "Content: text/html\n\n" as the first line." Jeff accepted "Oh - for output sure. But the input processing needs to be done - Form variables and all that are annoying to parse." Charles agreed - "thats the biggest job of the CGI library. usually thats all I use the CGI libraries for is variables and one function to print content header. some have included extra functionality like tables, etc."

Charles asked "have you thought about layout? ie. x,y cordinates" . Jeff said "Yup - Layout will be all CSS - So we'll use x,y from that. It won't be perfect, but thats fine." Charles said "I guess the #em stuff is "x,y" like" . Jeff said "It's really not ideal, but it's the correct layout solution for the medium." The alternative solution - tables (as used in the phpForms client that was no longer under active development) "gives an accurate layout but is fugly." "If we add some way of associating a label with its input widget, then we can easily use the non-table layout for accessibility needs, as well as PDA/Cellphone input." - this "would need another" field in the GNUe Forms Definition (.gfd). As most PDA/Cellphone web browsers could not render either graphics or tables, this was needed to make sure that the label ended up somewhere near the input field.

Charles said "in my case, also, I'm looking to integrate it with webmin.. I'm not sure if it will strip header text... besides that it should work fine possibly." He explained that "its basicly just a glorified cgi-bin" from the point of view of GNUe Forms, "but provides authentication, etc." .

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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.