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