|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
But can they code? - "/me went to the zoo today to see the 'big snake' exhibit - all i can say is python's are kick ass snakes - /me had no idea that they were so darn big"
Table Of Contents
|1.||15�May�2002||GNUe Package Management|
|2.||16�May�2002�-�20�May�2002||Development work on GNUe Reports|
|3.||18�May�2002�-�19�May�2002||GNUe Application Server planning|
|4.||18�May�2002||ODMG featuretest for GNUe Application Server|
|5.||18�May�2002�-�20�May�2002||Application Server roadmap|
|6.||19�May�2002||(1 post)||Curses (text-only) Forms client using nstti|
|7.||19�May�2002�-�20�May�2002||(2 posts)||GNUe Forms DTD|
|8.||19�May�2002�-�20�May�2002||(1 post)||Entity-relationship diagram for PAPO|
|9.||20�May�2002||(1 post)||i18n Support in GNUe Forms|
|10.||20�May�2002||Support for file-based databases in GNUe Common|
|11.||20�May�2002||GNUe architecture and project structure|
|12.||20�May�2002||Multi-platform GNUe Applications|
|13.||21�May�2002||Sub-reports in GNUe Reports|
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.
1. GNUe Package Management
15�May�2002�Archive Link: "[IRC] 16 May 2002"
People: Jens M�ller
In the midst of several Star Wars spoilers, Jens M�ller (ICJ) asked "about package management" , noting "dpkg or rpm certainly have good routines concerning conflict resolutions - is it possible to put them into GNUe ?" . (See also previous discussions in Issue�#15, Section�#7� (4�Feb�2002:�Private GNUe applications and GNUe Templates) )
2. Development work on GNUe Reports
16�May�2002�-�20�May�2002�Archive Link: "[IRC] 17 May 2002"
Topics: Reports, DCL
People: Derek Neighbors,�Jason Cater,�David McWherter
Continuing Issue�#29, Section�#27� (13�May�2002:�Mail-merge with GNUe Reports) , Derek Neighbors (dneighbo) reported that master-detail reports "doesnt choke now but not sure how to use it for out put" . He asked "can i put section tag inside the record?" . Jason Cater (jcater) confirmed this. Derek pasted some sample XML. Jason confirmed "that's how detail datasources work in reports" . Derek said he had to put "the name of the field in the master table" in the XML, but "if i leave that i bitches thats not a valid field - if i change it a valid field in the detail table instead it barfs" . He was not sure if "this could be something in my syntax - or it could be in the code" .
Some days later, Derek Neighbors (dneighbo) said "i about have my reports ready for demo" , although it was not really production quality as of time of writing. He had found that "php exec/system calls are pretty freaking weak wrt: debugging - but now i at least have a SIMPLE script where if you hand it WO/SR number it prints my form :)" He asked Jason Cater "were you able to fix master/detail in reports - it would be more impressive for demo tomorrow but not mandatory :)" Jason said he would "try to look at tonight - I'm sure it's not a big fix - as it was working" . Derek said one of the problems he had had was using the file extension for Forms rather than Reports "out of habit" and php had not given him a sensible error message.
Later, Derek reported "hey i have dcl using gnue reports as of um - 30 seconds ago" . He had been "able to rather easily hack in to a dcl workorder template to make it call report engine" . He said that his employers might be willing to be a DCL/Reports reference site. David McWherter (dtm) suggested "push that dcl logo proudly, my friend" . Derek said "um im pusing it as GNUe DCL :) - which doesnt have a logo" .
Derek asked how to "do conditional/compound queries" in Reports - he needed "to do an AND and have the and hard coded :)" . Later, Jason said "you can do: and or not eq ne lt gt le ge like notlike between notbetween and any nested combination thereof - oh, and: add sub mul div - I'm sure we put some more in there - boy, someone should document this stuff <cough>" .
The next day, Derek said "wish me luck, i go to present gnue dcl in 5 minutes to the 'big boys'" . Several people cheered him off. Later, he reported "well presentation went really well, but its rather possible we have already lost due to the purchase of support magic" . However, "on a good note EVERYONE there seemed to like it - and most wanted to switch now - which is highly promising even if we lose" .
3. GNUe Application Server planning
18�May�2002�-�19�May�2002�Archive Link: "[IRC] 19 May 2002"
Topics: Application Server
People: Jan Ischebeck,�Andrew Mitchell,�Reinhard M�ller
Jan Ischebeck (siesel) asked what "the short name for the "object server" in neilt's drawing" was. Andrew Mitchell (ajmitch) referred to gnue/docbook/Proposals/geasarch/neilt-arch-explanation.txt, and suggested "GNUe Object Access Translator (GOAT)?" . He noted the documentation said "This is the main part of the Application Server. GOAT uses GEDI and GEMA to fulfill requests directed at business objects, after it has checked the validity of the request against GEOR."
Jan noted that "neilt want's a "object server" who has MVC (modell view controller) capabilities. I don't know exactly if this is compatible with standart transaction and locking schemes. (like the ones in an ODBMS) " . He thought "there is the need to make more agreements about the kind of "application server" we want to implement. Everytime beginning with a new component for my "_featuretest" approach, I'm quite unsure if someone agrees with my thoughts."
He asked whether "real "objects" will exists in any stage of the appserver or does GOAT just simulates objects out of a combination of data stored in sql DB tables and methods provided by GEMA?" . Reinhard M�ller (reinhard) explained "my plan was to not have python objects - although it seems as it could be easy so it'd be cool to have - but primarly we will have objects that are accessed through the defined api (via geasInstance)" . Jan asked "But if you create geasInstance for each table row. why not directly creates an real python object which inherites geasInstance?" Reinhard said "if it's easy then we will do it - however other languages are not as flexible as python in creating new classes dynamically - and eventually we will have other language bindings than python for geas" . This would mean "the geasInstance way will still exist" , since "the dynamic class will be on client side imho - i.e. the geasInstance will go through the rpc module - and be converted to a e.g. customer object at _client_ side" . Jan agreed that this "could make the programming of the database adapter easier and it will work with every programming language. But there should be an option to have direct access on the objects. (which is really easy to implement in python)" , giving an example. Reinhard said "that looks good and sane - however do you agree that this would be client-side (RPC wise) ?" Jan thought that "the trigger code wants to use this feature too, so it would be better to implement it "server-side" - An other possibilty is to write the code once and use it for triggers at the server side and for "getAttribut1" Access at client side" . Reinhard thought this was "better" .
The next day, Reinhard asked Jan whether his latest commits meant that "forms work with geasv2??" Jan confimed this "but just read only. and without conditions" as of time of writing. Jan asked for "specifications for reading informations about a table, like supported fields, ... and a specification what kind of arguments are passed to setConditions :)" Reinhard suggested "define pseudo-objects - so we can use the same interface to get that information as we use to get real data" . He agreed about setConditions.
4. ODMG featuretest for GNUe Application Server
18�May�2002�Archive Link: "[IRC] 19 May 2002"
Topics: Application Server
People: Jan Ischebeck,�Jens M�ller,�Reinhard M�ller
Jan said he had comitted to CVS a " gnue/appserver/src/_featuretest" file, which was an attempt "to implement some ideas from odmg.txt and an book about object servers." . He explained "the idea of _featuretest is to have a kind of "object server" which is very very simple, but which has objects to implement the rest of the server funtionality. Because this objects are objects of the objects server they can be updated and reloaded on a running system, and the most important: they can be stored and loaded from a database. I.e. you can store session states, class definitions, normal objects with the same code." Jens M�ller (ICJ) said "I understand the trigger stuff better now" . Reinhard M�ller (reinhard) suggested discussing it further the next day.
5. Application Server roadmap
18�May�2002�-�20�May�2002�Archive Link: "[IRC] 19 May 2002"
Topics: Application Server, Common
People: Andrew Mitchell,�Daniel Baumann,�Reinhard M�ller,�Derek Neighbors,�Jan Ischebeck,�Peter Sullivan
Derek Neighbors (derek) asked for comments on his idea in Issue�#29, Section�#6� (8�May�2002:�Application Server without object support) about doing a basic Application Server first, with full object support later. Andrew Mitchell (ajmitch) was worried that this would then "require another revamp to support objects?" . Derek said his concern was the time it might take to agree the object standards to be used in getting a full object-based Application Server up and running. Daniel Baumann (chillywilly) said that, if everyone was happy to use the ODMG standards, "there are no debates, imho" .
Earlier, Reinhard M�ller (reinhard) said "i still believe that is like saying let's drop apples and only do fruit - dbabstraction + triggers == basic object function IMHO" . Derek said that all he was suggesting for a first pass was "no need for a" GNUe Class Definition (gcd) file. Reinhard asked "where will we define what methods exist and where they are stored" in that case?
Later, Jan Ischebeck (siesel) suggested "I think we should do it the fast way. There is the need for a basic appserver in the next two months. But for the appserver which will be implemented in one year, i would like a more general approach." . Daniel asked "and the long-term one would be based on what?" .
The next day, Jan asked "do you think that appserver v.0.1 allready needs Object/ClassDefinitions? Or should it just pass arguments to and from the common dbabstraction layer?" . Reinhard said "we have to do a roadmap" , suggesting:
This would make "0.1 as the first version that really makes sense to use - with only basic fields (string, number, boolean, datetime) - then in 0.2 0.3 0.4 etc we add features like reference fields, list fields, indirect fields, calculated fields, triggers" . Jan suggested doing "reference fields = 0.3" for example. Reinhard said "i'm not quite sure about when to implement namespaces and especially on how to implement them" , explaining "namespaces == modules" . He was worried "if we can stay compatible if we add namespaces later - so we might have to do namespaces in first "official" version" .
Earlier, Jan asked "should appserver access more than one database?" Reinhard thought this would be a fairly late addition to functionality, but "1.0 should be able to" .
The next day, Reinhard told Jan "btw saw your ROADMAP and agree mostly" , but issues such as "introspection or support of more than one database or security concept" . Jan said he thought "introspection should be implemented when the GClassDef/GObjDef Stubs are added. that means before v 0.0.2" . Reinhard agreed - "if we decide to put class definitions in the database then introspection will be easy anyway" . Jan said "I think we have to put very very basic introspection support into v 0.0.1 just to make the dbadapter work."
Jan also suggested adding "0.0.4 has very basic security support (=login and password check)" to the roadmap. Reinhard said that it was probably best to have a firm roadmap to 0.1.0, "then add - Later (unsorted)" . Jan said he saw 0.5 as an "important milestone" as this "is the point where appserver supports transactions. i.e. appserver is getting usable in large enviroments, like 0.1 means usable for a small application." Reinhard wasn't sure whether it made sense to plan that far ahead - "what we could do is just list the post-0.1 features unsorted and decide about the order to implement them later - after talking to jamest and jcater about appserver and what they want to see - and maybe after getting experiences with 0.1 and seeing what is missing most urgently," adding "Planung ist die Ersetzung des Zufalls durch Irrtum" .
(ed. [Peter Sullivan] Planning is the replacement of the coincidence by mistake). Jan accepted this, but said "I would like to have a "Version 1.0 must have" in the roadmap. just to see what feature is really really needed" for that important milestone.
Reinhard asked "did i understand correctly that we need xmlrpc to connect forms with appserver?" Andrew Mitchell (ajmitch) said "it shoudl be able to run without xmlrpc for single-server installs - well, when forms & appserver are on same box" . Jan said "as I understand it : appserver needs GNURPC to run. but there is only XMLRPC working now." Other possible transports included "SOAP, Corba, piro..." Reinhard confimed that GEAS would use GNUe Common (and hence GNU-RPC) from the start for data access.
6. Curses (text-only) Forms client using nstti
19�May�2002 (1 post) Archive Link: "[Gnue-dev] nstti status update"
People: Gontran Zepeda
Gontran Zepeda reported his progress (as previously discussed in Issue�#29, Section�#7� (8�May�2002:�Curses (text-only) Forms client using nstti) ) "on the Not So Tiny Text Interface (nstti), a set of wrapper classes to the curses library module" , concluding that "nstti base classes aren't feature complete ;)" as of time of writing, but he would "simply add and enhance widgetry as needed" . He asked for examples of the "many excellent curses applications currently widespread" to garner ideas on how to implement some of the more non-obvious widgets in curses. He was hoping that "nstti may work on win32 via cygwin shell, probably no mouse though" , although this had not been tested yet. He posted a hyperlink to a sample screenshot.
7. GNUe Forms DTD
19�May�2002�-�20�May�2002 (2 posts) Archive Link: "[Gnue-dev] Problems in DTD [patch]"
People: John Lenton
John Lenton noted some "well-formedness problems" with "The gnue-forms.dtd" , giving examples and corrections. Later, he noted that his proposed correction to the "boolean" entity was still wrong, and asked "Maybe somebody with more XML than I can tell me if (why) it should be something other than <!ENTITY % boolean CDATA #IMPLIED>" .
8. Entity-relationship diagram for PAPO
19�May�2002�-�20�May�2002 (1 post) Archive Link: "[Gnue-dev] papo on savannah"
People: John Lenton
Further to Issue�#21, Section�#15� (20�Mar�2002:�Argentinian ERP development using GNUe) , John Lenton reported that "the first version of the" entity relationship diagram (ERD) for PAPO, an Argentinian-based ERP project using the GNUe Tools, had been posted on the web, and he asked for any comments.
9. i18n Support in GNUe Forms
20�May�2002 (1 post) Archive Link: "[Gnue-dev] i18n (internationalization)"
People: Arturas Kruikovas
Arturas Kruikovas said he would not be around for a while "because of exams" , but reported progress to date on i18n support, as previously discussed in Issue�#28, Section�#20� (6�May�2002:�i18n suppor in GNUe Forms) and other previous threads. As of time of writing, he had "almost finished i18n data, that depends on client (you can have menus and labels and etc. in your native language" ). "Data, that is taken from form (.gfd) itself, is not yet i18n, that is considered to be the next major step." .
10. Support for file-based databases in GNUe Common
20�May�2002�Archive Link: "[IRC] 21 May 2002"
People: Derek Neighbors
It was asked whether GNUe could run as a stand-alone application, using DBase files on a shared folder as a back-end database. Derek Neighbors (dneighbo) said "you would just need to make a driver for dbasefiles - i think someone was toying with using gadfly (or whatever zope's local db is)" .
11. GNUe architecture and project structure
20�May�2002�Archive Link: "[IRC] 21 May 2002"
Topics: Why GNUe?, Application Server
People: Reinhard M�ller,�Peter Sullivan,�Gilbert Nunya,�Derek Neighbors
Gilbert Nunya (Gilbertyoda) asked what language GNUe was written in, and got very enthusiastic when Reinhard M�ller (reinhard) confirmed it was python - "99.5 % of our code is python - the rest of 0.5 % is shell script ;)" Peter Sullivan (psu) explained "the original App Server was in C - the current re-write is in python" . He explained "a) people write appservers in java, which is if anything slower - b) if we get serious perf issues, we can optimise the key parts of code in C & link them in - as python is a good C wrapper" . Reinhard said "well if you hear psu talk you wouldn't think that he hasn't written a single line of code yet, would you? ;)" , adding "what scares me is that you can talk like a professional senior programmer :)" Peter said he "reinhard: I just repeat what Derek says - works for me ;-)" .
Peter said that GNUe was based on Python 2 - "Main problem is that most of the standard distros(esp Debian) are still stuck on 1.5.3" . He personally would "probably end up learning python when it becomes no longer necessary - i.e. by the time we have the Designer working with AppServer to allow you to graphically create triggers w/o knowing any python at all" .
Gilbert asked how he could contribute - "I don't wanna watch you guys have all the python fun!" . Reinhard suggested downloading CVS and seeing what area looked interesting - "gnue is a very big project and you have to pick your favourite part out of it" . Gilbert asked "do I need to know XML?" . Reinhard said "i don't know XML and i still pretend to work for this project" . Peter said that the transistion from HTML to XML was fairly painless - after all, "*I* understand XML, at least enuf to write it" . Gilbert wasn't convinced - "XML is one ugly mother" . Peter said "Eventually, most of the XML will be auto generated - already we have Designer set up to produce the XML for Forms definitions - and intend to use it for Report Definitions, App Server definitions, Navigator menu definitions... oh, and world peace and harmony between the nations" .
Gilbert asked about postgresql. Reinhard said "it's our prefered db backend" . Peter said "we work with shed loads of d/bs free and non-free" , noting "SAP-DB is now GPL" .
Gilbert asked about implementation timescales. Reinhard said "as most free software projects we have no fixed and planned release dates - it will be sooner if we have more people that help :)" Gilbert asked "how much python do I need to know to help?" Derek Neighbors (dneighbo) said "none" , since, as Reinhard said "you can also help by finding bugs, testing, making proposals on how to improve things, writing documentation..." . There were lots of different skill sets already in the project - "we have hackers with zero business knowledge as well as non-programmer accountants" but "everybody so far has been able to contribut something that wasn't there before" .
12. Multi-platform GNUe Applications
20�May�2002�Archive Link: "[IRC] 21 May 2002"
Topics: Forms, Designer
People: Marcos Dione,�Derek Neighbors,�John Lenton
Continuing Issue�#29, Section�#14� (9�May�2002:�Grids and scrollbars in Forms) , Marcos Dione (StyXman) asked "can I enlarge or shrink the # of rows, from the form?" Derek Neighbors (dneighbo) said this was not possible at runtime, but "you can make it say 10 or 20 or any number at design time" . John Lenton (Chipaca) asked "is there a design decision behind that, or is it just "not at this time"?" Derek said "there are plans to use real grids which would give you some resizing capabilities - but really i dont see much value in being able to 'add' more rows" unless resizing a form.
He added "remember gnue is designed to be highly portable to many platforms and be extremely quick to write applications - which means generally you will lose some of the 'pretty' fluff microsoft has taught you to love" . John asked "I was wondering if there was a way to get ctrees, but we thought nah they mustn't have done that because of the html, but then I saw the dhtml (your dcl_dict i think it was), and I said hey! that's how you do it with html! so where are the ctrees?" Derek said this was the same principle - how would you "do a tree on a palm pilot, or curses or with a telephone" ? He added "we are not opposed to such items, but because they cause other issues they are not super high on the todo list - but we would be willing to do or support as much as possible others efforts to do such things" . John felt "the curses point is rather moot seing as designer picks up its widget lists from wxwindows" . Derek said "we made a decision that for now designer would be dependent on wx - but applications should not - as we dont see a huge value in having a full fledge IDE for palm or the telephone :) - we do see value in having applications run there :)"
John asked "ok, but if we made the decision that a palm device, or curses, or telephone were out of the question for other reasons, we could hack in ctrees, right?" Derek agreed - "we plan on putting layers in - so that we can have 'non standard' items - like a cTree say - and 'official applications' would not use it" . John said "not unless we came up with a curses way of looking at ctrees :)" . Derek continued "we would disclaim that we cant guarantee that these 'extensions' will be up to date with newest version etc - but we wouldnt be unfriendly to someone wanting to write an extension" which might even get adopted as 'official' if it was useful and supported.
13. Sub-reports in GNUe Reports
21�May�2002�Archive Link: "[IRC] 22 May 2002"
People: Derek Neighbors
It was asked how complex GNUe Reports could get, and in particular whether sub-reports were possible. Derek Neighbors (dneighbo) said that there were "no charts and graphs" as of time of writing, and "subreports it kind of can do depending on how you define 'sub report'"
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.