| � | ||
|
Kernel Traffic Latest�|�Archives�|�People�|�Topics |
Wine Latest�|�Archives�|�People�|�Topics |
GNUe Latest�|�Archives�|�People�|�Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
"It is amazing in this business how much "new" technology is just a version of the old technology with a name that nobody ever heard before. It happens all the time and has been going on for years. Not exactly snake oil or ginsu knives, but I think some aspects of the sales approach are familiar. :-)"
Table Of Contents
Introduction
This Cousin covers the three main mailing lists for the GNU Enterprise project, plus the the #gnuenterprise IRC channel.
1. OLAP tools and pivot tables in Reports
31�Oct�2002�-�3�Nov�2002 (16 posts) Archive Link: "Subject: cross tables in reports?"
Topics: Reports
People: Sebastian Brosig,�Derek Neighbors,�Jason Cater,�Todd Boyle,�Stan Klein,�Gontran Zepeda
Sebastian Brosig asked "Can gnue reports, or any other Free database tool for that matter, create crosstables" - "i know the" Open Office "spreadsheet has the "Data Pilot" which is OpenOffice's answer to pivot tables but it's a point-and-click interactive tool and not a database" . Derek Neighbors said "Right now today. It can not do CrossTabulation. It will at somepoint support this. Furthermore, I am working to try to get a free OLAP implementation that GNUe can use as well. OLAP is pivot tables on steriods. :)" Jason Cater said "I will try to post an example pivot report done in GNUe shortly. Reports does more than you initially realize :) Of course, we don't have any sort of visual designer (yet), so it's rather difficult to see what's going on :(" . Todd Boyle felt that there was a distinction "between the goal of computing a particular crosstab at design time, versus providing users dynamic cross-tabs among a whole, balanced data surfing capability at runtime. The latter is of course much harder but turns out, pretty essential for managers to investigate and understand problems /oppties which, guess what. design time programmers cannot always anticipate." He noted that proprietary "OLAP vendors have been providing dynamic crosstabs for at least a decade, against large datasets usu. by precomputing various subtotals."
Stan Klein suggested looking at R, "a clone of a commercial language called S" which "appears to be popular among academic departments of statistics, who use and contribute. It might be worthwhile to look at producing GNUe output that can be processed by R or to consider an interface that allows R capabilities to operate on GNUe-managed databases" - "The combination of GNUe and R could make a very high powered strategic planning, forecasting, and data mining capability." He gave "an extract from the R Introduction manual discussing crosstabs" Derek said "I think the standard OLAP engine language for financials is a langaguage called A (im serious not being smart butt). There is a GPL implementation from Morgan Stanley (the original authors) called A+." Stan said "A+ is a variant of a language called APL ("A Programming Language") that, IIRC, was developed by an IBM researcher in the early 1970's" , which needed "a special keyboard to be able to input all the peculiar characters that it used" - "Think obfuscated C and go a few orders of magnitude worse. :-)" . By contrast, "R is a more general statistical package, similar in capability to SAS or SPSS, with the possible exception of the user interface." "I think the big users of R, besides academics, are probably strategic planners, market researchers, and scientific researchers, especially in the medical and social sciences where statistics are important." Gontran Zepeda said "It so happens I have spent part of the past couple weeks hacking up a kludgey perl *cough* package that interacts with R" . He felt that R had a "quite un-gnu like" . There were facilities for using python within R, but GNUe would really need something the othe way around - but R did have "a DBI type interface. That's right kids, get data from mysql, postgresql or plain flat files into your analysis space directly from R." He was not convinced that adding R as another dependancy for GNUe Reports was necessary, asking "Doesn't jamest have pivot tables working anyway?" Stan "took a look at the links on the R homepage and found something called RSPython that appears to provide interfaces both ways" between R and Python, although "It looks like you need to know something about the objects involved, so it's an interface that needs to be programmed for specific purposes." He suggested "The easiest way for GNUe to quickly do an interface (if desired) would be to write files using Reports in a format that can be read by R, use the Python to R interface to send R commands to read the input files and perform various functions, and then write the output from R to a file that could either be printed or imported to a database." He saw this as an add-on rather than a core dependancy. He also noted "there appears to be work ongoing on GUI interfaces for R, but it doesn't seem to be very far along. It might be nice to let the R folks know that GNUe might be a good candidate for that." Derek still preferred A+ as a general OLAP framework - and "To do general crosstab type of reports I dont think an additionalpackage is necessary."
Stan did some more research, and said that either OLAP or "Traditional statistical packages" could be used "for strategic business analysis." These both required human intervention, at least in specifying the analysis to do. Also, "There are also AI-based approaches under which the analytical tool searches for patterns in the data "on its own."" In general, "I detected a lot of "buzzwordism" in what I saw" and "when this kind of stuff is demo'ed it looks very "gee whiz" especially when stuff like 3D graphics are included." There were really two issues - "whether a free/open-source OLAP package can be built using A+" , which it obviously could, given effort. "The other issue is which of these approaches GNUe can support. I hope the answer is all of the above" , including R.
Todd said the most important part of a GNUe-linked OLAP tool was user-friendliness for the non-technical user. Quickbooks had dominated the small business accounting market, not because of any better functionality, but because it was perceived as more user-friendly. This was why he preferred something that built on existing experience of pivot tables. Jason agreed that "I see great value in getting GNUe to talk to existing OLAP tools" but pointed out that "GNUe *will* (pretty much does) support simple pivot tables/cross tabulation in its reports package. And, this does not/will not require any external OLAP packages" .
2. ODBC and native drivers for Unidata
31�Oct�2002 (8 posts) Archive Link: "Database Drivers"
Topics: Common
People: Jeffrey Walls,�Jason Cater,�Derek Neighbors,�Julien Munoz
Jeffrey Walls asked if there was "an open source Linux driver for Unidata" database. Jason Cater asked "Is this the Unidata that's part of IBM/Informix's UniVerse line?" Jeffrey confirmed this. Derek Neighbors suggested "Does Unidata have an ODBC driver (unix or windows). If it does I would just use the ODBC driver" . The main problem with ODBC was that there was no standard way to do introspection (e.g. find out the tables and fields in a database, but "If you are fluent with Unidata or can provide information for it, we can likely write custom Unidata ODBC GNUe Common driver that would enable introspection and the likes." As an IBM database, there would probably be a Linux ODBC driver for it. Julien Munoz asked "Does gnue use a "Database Adapter" concept like Zope ?" Jason said "Yes, we do. As a matter of fact, if you notice, there's about a 1:1 relationship between the databases that Zope supports and those that GNUe supports. That's no coincidence. We both use the same underlying Python API model for database access."
3. Halloween e-mails on AppServer functionality
2�Nov�2002�-�3�Nov�2002 (10 posts) Archive Link: "[Gnue-dev] Halloween 1: Terminology"
Topics: Application Server, Common
People: Reinhard M�ller,�Derek Neighbors,�Jan Ischebeck
Reinhard M�ller posted "a series of mails that sum up the results of the GNUe Hackers meeting in Frankfurt that took place at Oct 31, 2002" , as heavily trailed in Issue�#52, Section�#24� (21�Oct�2002:�GNUe Developers meeting in Germany) and other threads. They had started by discussing terminlogy - databases had things like tables and rows, fields, triggers and stored procedures. Object-orientated programming languages like Python, however, had classes and instances, attributes and methods. For business objects in an application server, more appropriate terminology was things like class, object, property and procedure.
They then discussed
Application Server's jobs, split into high priority (some of
which were already mostly or partly done), medium priority and
lower priority. There were other things that Application
Server would never do, as these were better done in other
tools such as the Javascript Forms client, Designer, the
GNUe Reports server, or GNUe Integrator. The next steps to
implement were:
"
"
Pre-requisites for this were to:
"
"
He noted "A major point of Appserver is to manage business modules." A module was simply "a group of class definitions that logically belong together" . Class definitions could be linked or extended between modules, creating dependencies. "Every identifier (class name, property name, procedure name) can be prefixed by the module name to fully qualify it." This would help avoid clashes with different modules using the same names. Underscores would be used to split module and name, for Python compatability.
He went on to propose the "new API of Appserver against Forms, Reports, and the Language Interface" , emphasising "Someone writing business rules will _not_ have to deal with this API." They would "be passed over the choosen RPC interface, which means that the actual definition syntax will depend on which interface is used." API commands would include opening and closing sessions, committing and rolling back data, requesting, counting and fetching lists, loading and storing objects, and calling methods.
Finally, he gave an ASCII diagram of "the planned internal architecture of Appserver" , including the Object Server, which provided the above API. The "Language Interface translates this API into native language (e.g. Python) constructs. That means that code using the Python Language Interface will see business objects as if they were Python objects." There was also a Code Interface manager, to allow procedures to be written in different languages and select the appropriate interpreter as required.
Derek Neighbors said "What I am not seeing here is that really method code should be the same as 2 tier trigger code." Reinhard said this had been agreed - however, the trigger code in Common might need some changes to handle AppServer as well. Jan Ischebeck noted that "the code in appserver to make methods work and the code in common for the trigger system have different design criteria" , but he would try to combine them if possible.
Derek agreed that classes needed to be storable in a database, but said he would like to be able to store them in flat files as well. Reinhard said "It will be possible to export the class definitions to flat files and import them from flat files respectively. This will be necessary (for example) for putting our class definitions into CVS. You can't commit a database table to CVS :-)" .
For authentication, Derek would like AppServer to use the same authentication "plug-in" as Forms - or alternatively, moved to Common so that both could use it. The same applied to Role Based Access Control (RBAC). Reinhard emphasised that the intention was to link AppServer to existing GNUe functionality/code wherever possible. Jan said "The "job" of both "plugins" are quite different. The authentification plugin in common FETCHES (f.e. from the user) authentification information to provide it to databases/middleware etc. for authentification. The auth. plugin of appserver gets some information (f.e. information, which was collected by the first plugin used by forms, reports etc.) and validates it. I really like the idea of having common, but I don't think that everything has to be moved into common at once. I would prefer to first implement the appserver auth plugin in appserver and wait till any other application needs stuff like that before moving it into common." Likewise, with RBAC, the "First priority is to implement it, so that appserver can use it. If forms, reports etc. can use it too, its a nice side effect. But forms, reports needs a much different and more advanced security structure, so IMHO it isn't worth the effort. It could even make common work slower. (I don't think that the user of reports would like that)" . In general, he wanted to give AppServer room to develop without having to port everything to Forms or Reports via Common.
Derek said "This is the view that I feared, that supporting things in the other tools would be an after thought instead of a forethought. Again I think the developers of the tools need to discuss some before implementation and they can as a collective decide what to implement where." "My fear is that to use anything in GNUe you will need appserver. Putting things like security and triggers in appserver only means that you woudl have to use appserver to get at those features. This is not acceptable according to our mission of 'all tools can be used independently or together'." He did not want to force developers to use n-tier rather than 2-tier just to access specific functionality. "I think anything that more than one tool needs, should be in common" .
However, after further discussion, he was more comfortable. "The mission statement I thought we might have been violating was "All the tools shall be able to run independent as well as together." From the response here, it sounds like that is not an issue and that it is on the fore fronts of those doing the appserver work. Which is very reassurring."
4. Debian packages into sid (unstable) distribution
6�Nov�2002 (1 post) Archive Link: "[Gnue-announce] New Debian packages - now in sid!"
People: Peter Sullivan,�Jeff Bailey
Further to Issue�#54, Section�#21� (4�Nov�2002:�Debian packages into sid (unstable) distribution) , Peter Sullivan announced "Thanks to Jeff Bailey, we now have Debian packages in sid (the Debian unstable distribution). These packages are based on CVS rather than the recent 0.4.0 release, and hence are in effect a "0.4.1-alpha"." They should be available "from your favourite local Debian mirror " .
5. Adding functions to Trigger namespace
6�Nov�2002�Archive Link: "[IRC] 07 Nov 2002"
Topics: Forms
People: Dmitry Sorokin,�James Thompson,�ra3vat
Dmitry Sorokin (ra3vat) noted that the version of GNUe Forms maintained by Project Papo "has about twice more functions in trigger namespace - is there any purpose to keep ours such limited?" James Thompson (jamest) said "i setup the trigger namespace so it could be easily extended then I sat back and let others extend it - /me is lazy like that. I'm hoping that we can start looking at merging the two trees in the very near future - or at least setting them up as a branch in our cvs until we can work thru the changes" .
6. Other GNUe Forms clients
6�Nov�2002�Archive Link: "[IRC] 07 Nov 2002"
Topics: Forms
People: Peter Sullivan,�Jason Cater,�James Thompson,�Charles Rouzer,�Derek Neighbors,�Jan Ischebeck
Peter Sullivan (psu) said the "web site has been updated to include brief descriptions of the non-main Forms clients" . Jason Cater (jcater) said "the Curses and GTK are slightly different than the others - java, emca, php are separate forms clients - curses, gtk, and wx are modes of our main, reference client" . James Thompson (jamest) noted "the java client is so old i bet it'd be a major overhaul to get it to even remotely function" . Jason said it was just some code stubs in CVS. Charles Rouzer (Mr_You) said that "Jans javascript code" , as discussed in Issue�#52, Section�#22� (20�Oct�2002:�Javascript forms client) , "could replace JForms" . Jason noted that Javascript was not intended to be the definitive html mode for GNUe Forms, but encouraged Charles and Jan Ischebeck (siesel) to work on the Javascript version as an alternative. Charles felt it would be difficult to write an effective HTML client without using Javascript.
Derek Neighbors (revDeke) said there were two types of GNUe Forms client - ones that were in effect just UI drivers plugged into the main python code, and complete re-writes such as the phpForms and Javascript Forms client. Each of these two types could either official (in GNUe's CVS) or unofficial.
Charles noted that people could either use the normal Forms client in 2-tier mode, or the Javascript Forms client (which would require Application Server) in n-tier mode. Derek said the point of GNUe was that people could just use the tools they needed - "you could use an HTML client w/ or w/o appserver - w/ or w/o reporter - w/ or w/o integrator" . Charles appreciated this, but asked "how you would expect to get persistent connections using a webserver and HTML client?" Derek said that he would expect an HTML client, just like the wxPython client, to allow devlopers to use either AppServer, or connect directly to the database using GNUe Common. Charles said this would still require an extra componant to make it "persistant-like," whether that was Application Server or a web server. Jason said "gnue-forms can stand by itself and communicate back to a webbrowser - there's no magic to that" . It used the normal python libraries to, in effect, give itself a built-in web server for HTML clients - this "formed the basis of the initial gnurpc implementation" . This removed the need for either GNUe Application Server or a stand-alone web server running Forms via cgi.
Charles still felt "that js is required for dynamic screen writes.. you build the layout code into JS then add on xmlrpc and 2-tier connectivity" . Derek noted that there had been a UI driver for the standard Forms client that used webware to support HTML clients, which had worked to a degree. He felt that this approach would be less work than trying to rewrite the whole Forms client in either Javascript or even php. There was no reason why an HTML UI driver could not use Javascript for dynamic screen writes and so on, although Jason was keen for the HTML client to not require Javascript, but use if is if was available. Derek said "the biggest thing that becomes an issue is client side triggers - but the data stuff and such i see no problems" .
Jason said that a Forms client completely re-written in Javascript would probably "be a better experience for the end-user BECAUSE it is a specific, targeted version of forms BUT that doesn't mean we don't want a version using our gnue-forms core" as well. He was "happy you guys are doing a jsforms client" as "another implementation will keep us in check and it will be something very useful" but "that doesn't negate use having a more general purpose one in gnue-forms even if it's not as robust/user friendly" . Jan Ischebeck (siesel) concluded "1. choices are good - 2. there has to be ONE standart implementation (more than one will allways become unmaintainted) - 3. jsforms should be so modular that you can easily implement" different set-ups.
Looking at the web site, James Thompson (jamest) wondered if it would "be cleaner to have 1 page on the reference client with #section tags for the various drivers - as I know that I want to see a native win32 driver and a qt driver - and I'm sure we need an emacs driver too :)" Peter said "The main justification for separate pages is that each mode of the ref client may have diff statuses - and it's confusing to have too many "Status" lines on one page" . Jason said he "would still rather see" information about other Forms clients in a subdirectory - "as I think /tools/curses is ambiguous considering we have a curses navigator too" . James added "reports almost has a curses and wx mode i think" . Peter said he would "fix that in the pending site overhaul for when we get it into CVS" .
7. CSV driver for GNUe
6�Nov�2002�Archive Link: "[IRC] 07 Nov 2002"
Topics: Common, Integrator
People: Derek Neighbors,�Jason Cater
Further to Issue�#54, Section�#27� (5�Nov�2002:�Adding a CSV 'database' driver for Integrator) , Derek Neighbors (revDeke) said "i think good things were discussed, but im curious about making db driver more complex than need be" - "as generally there are two types of things - csv files in which you wnat to read and write and csv files which are used to 'move' data" . He agreed with Jason Cater (jcater) "in the dont assume 1 line - some wierd files dont start data until two or three lines in" He was not sure about random access read-write, however - "i.e. is it only valid for import/export" . Jason said "well, I wouldn't expect to run GNUe Forms off of it - I suppose one "could"" . Derek was not keen on defining CSV formats in the connections.conf file - he thought that sort of thing belonged in the .gmd (GNUe Mapping Definition) in Integrator. Jan agreed - if nothing else, the filenames would be changing even if the structure was not. Jason agreed - "I'm really thinking, wherever you define it, this really boils down to a <datasource> issue" - he felt both ways could be useful.
Reflecting back to Issue�#43, Section�#6� (16�Aug�2002:�Integrator and schema import wizard) , Derek said that "integrator is just a different front end to reports" . Jason said that it was a tool to provide a mapping layer between datasources "to do complex stuff (with triggers if need be)" . "in my mind.. it's reports with a SINGLE destination... another datasource :)" Derek felt "that the CSV driver to me is a HUGE first step for integrator - ie. i have needs for integrator but mostly with CSV - as soon as we have CSV driver i can start to torture test integrator with sample usages :)" .
8. GNUe's Event system
6�Nov�2002�Archive Link: "[IRC] 07 Nov 2002"
People: James Thompson,�ra3vat,�Dmitry Sorokin
Dmitry Sorokin (ra3vat) reported some error messages for Unknown Events. James Thompson (jamest) explained "events are now defined per object instead of globaly - so if you've events on objects we've missed then they won't fire" . He gave an overview of the event system. "any object can register to listen to any other object (basically) - however that object may only understand what to do with a few of those events. Example: so if you and i both did something crazy like register to listen to derek - and derek says "jump off a bridge" I may know how to jump off a bridge so I go do it - you on the other hand don't know how (or are too smart to listen to him) and instead say "Unknown Event: jump off bridge"" .
9. Zope as an Application Server
7�Nov�2002�Archive Link: "[IRC] 08 Nov 2002"
Topics: Application Server
People: Bill Gribble
Bill Gribble (grib) asked how GNUe Application Server related to Zope. "it has many of the properties of an application server and gives you a lot of freebies. and it's already python. For example, the ZPT mechanism and TAL/METAL could be used to process a report definition (in XML) into a filled-out report (in XML) - essentially for free. Since it already talks XML-RPC every which way it seems like it could interoperate with some of the existing gnue stuff, no?" He did not "have enough experience with the state of the art in gnue to really know how the pieces fit together" so he was not sure if this was sensible or not.
10. Feature plans for GNUe
7�Nov�2002�Archive Link: "[IRC] 08 Nov 2002"
Topics: Forms, Reports, Common
People: James Thompson,�Jason Cater,�Jan Ischebeck,�Derek Neighbors
Further to Issue�#54, Section�#24� (4�Nov�2002:�GNUe Project organisation - version numbers, roadmaps, testing and branches) , James Thompson (jamest) said "i know people have said that the roadmap exists only in a few heads of the developers - in an effort to do something about that I present" a feature-plans document for Forms and Reports. The format was based on the feature plans for KDE - "while it's not as strick as a roadmap it does attempt to give people an idea where things are going - how we think it'd work - as the 0.5.x releases progress things get moved from the red area, to the yellow, then to the green. 0.6.0 will not appear until either everything in 0.5.0 section is in the green OR something causes us to move items holding us back into a later release section" Jason Cater liked "KDE's release plans better than the traditional roadmap you see w/projects as it is more fluid - and, I think it fits our model of development better" . James asked "so should jason and I continue to work on these or are we waisting our time?"
Jan Ischebeck (siesel) asked "how are/will be the feature plans updated? CVS? ...?" James said "right now it's horrible - vi and raw html. I'm pretty sure I'd like to see someone make some databases and gfd files we can run on" the web server - "then force our webmaster to write some php to create the pages in realtime" . There were "placeholder" pages for the other GNUe Tools as well, but "the only ones that have been worked on are common, forms, reports - and then only a little" .
Derek Neighbors (revDeke) appreciated James and Jason's efforts, and said "im fine with calling it a featureplan as thats what i pretty much am defining by saying roadmap - i.e. a list of what features are targeted for what release. I woudl call it release schedule but that sounds like it has a 'time' connotation and we all dont want that." The format was also helpful in terms of defining what he needed to add to DCL, GNUe's own bug/task-tracking system, so that these could eventually be generated automatically - "already i plan to add 'versions' properly into DCL" . Jason said he had considered doing the feature plans in DCL, "but I'm a little concerned about the flexibility" . Derek agreed - "for now i would suspect that DCL be done to track the work (bugs) not so much plan it" . For the moment, "im sooo happy to see loose feature lists - i dont want to get out of control" . He would add "All outstanding critical bugs in dcl, if any" to the lists.
11. Data browser and Dynamic Forms
7�Nov�2002�Archive Link: "[IRC] 08 Nov 2002"
Topics: Forms, Designer, Application Server, Common
People: Jan Ischebeck,�Jason Cater,�James Thompson,�Derek Neighbors,�Reinhard M�ller
Jan Ischebeck (siesel) said he and Reinhard M�ller (reinhard) had "talked about autocreated forms out of database metadata." . Jason Cater (jcater) said "you could almost take the Designer wizard examples and use them as is to do that (well, and make them non-interactive)" . He was not sure whether this belonged in Forms or AppServer. James said "i think they want a data browser - point forms at a database and it opens a tree - click on a table and it opens a grid" . This would enable him to stop using pgaccess, which he was not keen on. Neither Derek Neighbors (revDeke) nor Jason were really sure this functionality belonged in Forms, and Jason pointed out that you could pretty much do this from Designer anyway, by running the Simple Form Wizard and then using the Debug-Run menu option.
Derek thought "maybe what people are wanting is dynamic forms - i know thats what the" Application Server developers wanted. He personally would probably use static (flat file XML) form defintions mostly, but he could see the need for something more. James suggested "wouldnt this data browser be fairly simple standalone app" using GNUe Common and wx, rather than part of either Forms or Designer. Derek said "im thinking maybe its a 'plugin' to designer - that could be called indpendently. I see many of things in designer being like that - where you can access them from within designer or launch on their own" .
Jan said "reinhards idea was NOT to have a data browser, but to use dynamic forms for 80% of all cases." Jason asked "wouldn't that be something appserver serves up?" Reinhard said that Forms would be better at doing dynamic forms, as it would be aware of what font sizes and screen size it was working to. Jason said "actually, no forms definitions ever mention point sizes or anything like that" - that was up to the UI (user interface) driver.
Derek said this might be as simple as just tweaking the current Simple Form Wizard in Designer to produce its GNUe Forms Definition (.gfd) as an XML stream instead of a file, and passing this to Forms - "i think thats a plus of dealing with xml in this case is forms shoudnt care if the definition is coming from a file or directly from a stream" . Jason pointed out that "it doesn't fit in with any model of forms client we have... the client is always given a definition" . Derek said that, in practice, he would probably expect some other tool (possibly GNUe Common) to "prebuild streams and hand it to forms" . By putting the dynamic form generator in Common, any GNUe tool could use it - "you coudl have a form that called a trigger to make a dynamic form - rofl that would be funny" .
12. DCL release plans
8�Nov�2002�Archive Link: "[IRC] 09 Nov 2002"
Topics: DCL
People: Derek Neighbors,�Jeff Bailey
Jeff Bailey (jbailey) asked if much had been added to DCL since the last release. Derek Neighbors (derek) said "dcl has LOTS of new goodies - i just havent tested them all. I hope mdean is around as it might be this weekend - i had my side pretty much done - he was fixing new nested product stuff" . Jeff asked "What's your integration plan with DCL and the rest of GNUe?" Derek said "for right now, my goals are to get it doing some stuff to help with managing consulting operations and gnue - then start migrating it to gnue - it already uses GNUe Schema Definitions" . Also, "my production implementation uses GNUe Reports - i will likely author some reports for it with GNUe Reports and put themin the DCL distro. There are several gfd's for it" . Jeff said he would do a revised version of the Debian packages for DCL or any of the GNUe Tools whenever he was told there were enough new features to make it worthwhile.
13. Master-detail blocks in Forms
8�Nov�2002�Archive Link: "[IRC] 09 Nov 2002"
Topics: Forms
People: Dmitry Sorokin,�Derek Neighbors,�Jason Cater
Dmitry Sorokin (ra3vart) asked "what is master and detail when we talk about blocks in form?" Derek Neighbors (derek) said "master/detail is parent/child" , giving the classic example of invoices and invoice item lines. Dmitry asked "shouls i put child block inside parent? <block name="parent"> <block name="child"></block></block>" Derek said he normally put the blocks after each other. Jason Cater (jcater) confirmed "blocks aren't meant to be nested - I really don't know what would happen - but I wouldn't recommend trying :)" Dmitry asked "how blocks will know they related? by datasources assigned to them?" Derek said you used the masterlink="" and detaillink="" attributes on the datasource tag to define the linked (master and detail) fields. He thought "you can define parent child stuff in the blocks as well, but i havent done it that way" . Jason said that was depreciated "since 0.0.x series" .
Dmitry said he had been trying to do master-detail using triggers. Jason said "you don't really have to use many triggers to get functionality out of forms - triggers will usually be for special validation - or such similar polish" . Derek agreed - "forms internals does most DATA work" .
14. wx Mouse Paste in Forms not working
8�Nov�2002�Archive Link: "[IRC] 09 Nov 2002"
Topics: Forms
People: Dmitry Sorokin,�Jason Cater,�ra3vat
Dmitry Sorokin (ra3vat) reported a problem with GNUe Forms - "if i paste something in entry by mouse it is only looks like it is pasted but i was unable to edit even commit that info" . Jason Cater (jcater) said this was a "known bug - for some reason, when you use the mouse to paste wx never generates an event - so we never know it happened :( - we're still chasing that one down" .
15. GTK2 driver for Forms on Microsoft Windows
10�Nov�2002�Archive Link: "[IRC] 11 Nov 2002"
Topics: Forms
People: Bajusz Tam�s,�James Thompson
It was asked whether GTK2/libglade was stable on Microsoft Windows yet. Bajusz Tam�s (btami) said it worked quite well - using the GTK2 driver for GNUe Forms on Windows worked better than the wx driver - it "isn't full featured IIRC - but hasn't got that ugly bugs like "focus nightmare" and "tabbed pages" problems" . James Thompson (jamest) asked "how hard is it to get the gtk2 driver running on any platform? i thought it required custom patches to gtk or something - so avoided it for now" . Bajusz said that, on Windows XP, he just had to "downloaded the necessary stuff from sourceforge - and it worked" - no need for cygwin.
16. Forms for very large tables - block/page limitation
10�Nov�2002�Archive Link: "[IRC] 11 Nov 2002"
Topics: Forms
People: Bajusz Tam�s,�James Thompson
Bajusz Tam�s (btami) reported "a problem with pages and blocks - i have 1 table with many fields, and want use tabbed pages, but with only one datasource and one block" . James Thompson (jamest) said that the code assumed a block would not spread across multiple pages. This limitation had been inspired by similar functionality in equivalent proprietrary products - "have fields display across pages is in the forms TODO - the blocks nested inside pages have been around since the start - I'm not saying were tied to that idea only that is was the 1st implementation and we've never adjusted it :)" This would probably not change until they provided a way to repeat fields across different pages - "What we want to provide is a way to say this field belongs on all pages, or on pages 1, 3 and 5, or on page 1 - however I wouldn't expect this feature until after 0.5.x series is complete" . Bajusz said his problem was more immediate - "what to do if i have 1 table with 100 fields and want tu use 1 form" . James admitted "right now you're going to suffer :)" - he "never thought about that size table when I did the page inside block thing" . For "a very nasty workaround" he suggested "make a master/detail/detail/detail setup - all using the same table" . However, "It would be ugly to setup, editing would be a major pita. Is this page limitation going to be a showstopper for you?"
17. Latest psycopg driver version breaks Designer wizards
10�Nov�2002�Archive Link: "[IRC] 11 Nov 2002"
People: Jason Cater,�Jeff Bailey,�James Thompson
Jeff Bailey (jbailey) tried to run the Simple Form Wizard from inside Designer against a PostgreSQL database. Jason Cater (jcater) warned "check your psycopg version" - versions 1.0.13 of this python-to-PostgreSQL driver was known to have issues, as "either they changed the API or have a serious bug" . Jeff tried anyway, and asked "Is there a good way to make the input boxes more than 0 pixels wide?" - the wizard was setting them with a default width of minus 5. James Thompson (jamest) said "the default size is based upon the size reported by the database" , which suggested a serious problem with the pyscopg database driver. He suggested either using an older version of psycopg, or the popy or pgsql drivers instead.
18. Sloppy queries in Forms
11�Nov�2002�Archive Link: "[IRC] 12 Nov 2002"
Topics: Forms
People: Derek Neighbors,�Dmitry Sorokin,�ra3vat
It was asked how to search for part of a field. Derek Neighbors (dneighbo) said "if you have field name do f8 in the name entry - do ra% - hit f9 it should return all results starting with ra" . Also, "there is something called 'sloppyquery'" - "if you put sloppyquery=""" into an entry definition, then "everytime you execute a query it will" put a SQL wildcard character (%) between each character - this "fires onProcessQuery" . Dmitry Sorokin (ra3vat) confirmed that the code for this was currently commented out - using the sloppyquery="" attribute did not crash Forms, "but search fails" .
19. setup-cvs.py for Microsoft Windows
11�Nov�2002�Archive Link: "[IRC] 12 Nov 2002"
People: Arturas Kriukovas
Further to Issue�#45, Section�#3� (23�Aug�2002:�Setting up CVS versions of GNUe on Microsoft Windows) , Arturas Kriukovas (Arturas) said he had an almost-working revised version of setup-cvs.py (in CVS as setup-cvs2.py) which should work on both Microsoft Windows and GNU/Linux. This still needed some more work, however.
20. Object repository in Application Server
11�Nov�2002�Archive Link: "[IRC] 12 Nov 2002"
Topics: Application Server
People: Reinhard M�ller,�Ariel Cal�
Reinhard M�ller (reinhard) thanked Ariel Cal� (ariel_) for his draft "object repository document you sent me" . He was "not sure if we want to include inheritance at all - and if we want to include versioning and compounds in the very first version" . He felt that some of Ariel's tabular explanations were clearer than the XML versions. He asked Ariel to send him a graphical version of the AppServer architecture diagram, so that he could include it in the AppServer whitepaper.
21. Freedom issues with OpenMFG
11�Nov�2002�Archive Link: "[IRC] 12 Nov 2002"
Topics: Why GNUe?
People: Derek Neighbors,�Jason Cater,�Peter Sullivan,�Nick Rusnov,�Richard Stallman
Derek Neighbors (revDeke) noted "on newsforge they are running an article on openMFG - which doesn appear free, open or even available - and that well kind of got my goad. It was an interview - i took the liberty of responding to the same questions from a gnue standpoint" . Jason Cater (jcater) felt "I just don't see where they get off associating themselves with open source/free software - they are just trying to be the peachtree of the manufacturing world" . He noted that there were "several references to GNUe in the comments" as of time of writing. Peter Sullivan (psu) felt that openMFG's "(ab)use the open source label like this is almost a positive - shows that" Richard Stallman (RMS) "was right to insist on "free s/w" rather than "open source" as a label - as it's harder for people to twist that" . Nick Rusnov (nickr) was not so sure - "its easy to twist free software" as a label as well.
22. Curses (text-only) Forms client
11�Nov�2002�Archive Link: "[IRC] 12 Nov 2002"
Topics: Forms
People: James Thompson,�Jason Cater
It was asked how to run GNUe Forms in curses (text-only) mode. James Thompson (jamest) said "gnue-forms --interface curses form.gfd" should work - "do we need to install nstti from our cvs seperately?" Jason Cater (jcater) said not, but he was "not 100% sure setup.py has been updated to install curses for common" . In any case, curses support was only in CVS as of time of writing, not the last 0.4.0 official releases - "a preview will be in the 0.4.1 that we hope to release this week" and "it should be fully supported by 0.5.0" .
23. Planning for next release
11�Nov�2002�-�12�Nov�2002�Archive Link: "[IRC] 12 Nov 2002"
People: Jason Cater,�Derek Neighbors,�James Thompson
Jason Cater (jcater) announced "After the next point release, we are moving away from" reporting version numbers for CVS versions of the software in the format 0.4.1a, and would do them as 0.4.0.99 instead, to avoid breaking upgrades on Debian and other packaging systems. In the meantime, he had the "first set of prereleases for 0.4.1" on the web site. Derek Neighbors (revDeke) asked if Debian packages could be done for these, but Jason felt they were "not ready for debs yet" . Derek said he wanted to "pay more attention to the release" , as he would be looking to take responsibility to port any major bug-fixes back to the 0.4.x series (as a "stable" branch) once Jason and James Thompson (jamest) had moved on to 0.5.0.
The next day, Jason announced "New prereleases (-pre2)" , listing the chages since -pre1. He was now in feature freeze mode (unless bribed with donuts), as "We are prepping up for a weekend release." .
24. Sample database for all GNUe Tools
11�Nov�2002�Archive Link: "[IRC] 12 Nov 2002"
Topics: Common
People: Jan Ischebeck,�Jason Cater,�Derek Neighbors
Jan Ischebeck (siesel) asked where to put test forms. Derek Neighbors (revDeke) felt these belonged in CVS, in the samples directory. Jan thought "that every feature needs an implementation by an form/report etc. which can be used for testing as for learning" . Jason Cater (jcater) said "I want to rm -rf samples and start all over. I want one interesting schema with sample data and all - and all forms / reports / etc use this schema/ theme - and I want to use the same schema/theme in the developers guides - much like Access' Northwind (or whatever) test database - and I don't find zipcodes interesting :)" Derek said this "sounds like gnue-sb :)" (GNUe Small Business edition). Jason said "maybe a simple version of that only 2-3 tables - anywho - that's not going to happen this release - but I would like to see it in 0.5.0" .
Derek said he had a demo database "that i use for demos - its a video catalog database" . Jason liked that - "most people can relate to it" . Derek said it had a very simple schema - "one main table and a few foreign key tables for type = vhs, dvd etc and rating = R, PG, PG-13" . Alternatively, "ideal for me would be a music database - CDs parent - Songs Child - lots of lookup tables for year put out, label etc" . This would also demonstrate "some cool triggers as i want to tie it into CDDB :)" . Jan wondered if "a sample application for gnue should have connections with business" . Jason was "not sure I agree because a sample with a pure business theme will tend to try to outgrow itself and try to become an actual app" . Derek said he would come up with a schema in .gsd (GNUe Schema Definition) format over the next few weeks.
25. GNUe Schema Definition (.gsd) file formats
11�Nov�2002�Archive Link: "[IRC] 12 Nov 2002"
Topics: Common
People: Jason Cater,�Jan Ischebeck
Jason Cater (jcater) noted "postgres uses a funky definition for precision" which the XSLT files to transform a general .gsd (GNUe Schema Definition) into PostgreSQL-specific SQL could not handle as of time of writing - "we are working on the schema system - trying to get it back together - it has been totally trashed" . Jan Ischebeck (siesel) asked why there were so few data types in .gsd - no distinction between integer and float numbers, and "varchar and char the same?" Jason said "that was not the direction we were wanting to take gsd" . Jan felt that "its quite different if you use varchar or char, as it is between float and number" .
26. Demo GNUe Application at Oracle World
12�Nov�2002�Archive Link: "[IRC] 13 Nov 2002"
People: Pradhep D.
Further to Issue�#53, Section�#2� (24�Oct�2002:�GNUe support for Oracle 9i) , Pradhep D. (Varadhan) announced that California Digital had "setup a stall in ORACLE World, with gnue+roacle9i on a IA64 debian machine..." This was "a sample banking application is written using gnue+oracle 9i and has been setup there for the show..." It "allows creation of an account, modification of account info, closing of accounts, depositting into an account, withdrawal from accounts, querying of account balance etc.." They would be interested in meeting any members of the GNUe community who could attend.
27. i18n issues with Reports
12�Nov�2002�Archive Link: "[IRC] 13 Nov 2002"
Topics: Reports
People: Bajusz Tam�s,�Jason Cater,�Dmitry Sorokin,�Arturas Kriukovas,�ra3vat
Dmitry Sorokin (ra3vat) was having problems using GNUe Reports with i18n (internationalisation) Bajusz Tam�s (btami) said "it seems something puts charset=UTF-8 into html header" . Jason Cater (jcater) volunteered "if someone can whip me up a simple report that fails with i18n, I can debug" . Bajusz said it seemed to "be any report that pulls db data not in ascii, i suppose - you use dest.write ('<?xml version="1.0" encoding="ISO-8859-1"?>\n') in GRReport.py" . Jason thought "there's more to it than just changing that header, though - I think I have to open a codec - which I learned to do this past weekend by accident" . Bajusz said "you don't have to deal with codecs, if sitecustomize.py" was set up to set all locales. Dmitry Sorokin (ra3vat) believed that Arturas Kriukovas (Arturas) had got it working without having to do this, but he was not sure of the details. Later, he found Arturas' commit message - "Corrected problem of i18n characters in .gfd file - in case of not only ascii characters, sax returned unicode string, which caused further errors in python. Earlier this was solved by changing system-wide site.py file option defaultencoding from 'ascii' to other value. Now encoding is read from gnue.conf file option formFontEncoding and is used to enforce sax returned unicode string recode to given encoding." Bajusz said that this "solves the gfd's problem, but what about data (from DBMS) ?" Dmitry said that his "problem was that xml processing enforces internal representation in unicode - it is not with db data - you know db encoding and can convert to other encoding if you wish" . Bajusz said he was "thinking about reports - it makes an intermadiate xml file with dest.write() calls - and then a sablotron process comes. I don't know/when how UTF-8 comes" into the process. Dmitry said that "UTF comes as far as you use xml processing libs (parsers)" .
28. Producing labels from Reports
12�Nov�2002�Archive Link: "[IRC] 13 Nov 2002"
Topics: Reports
People: Jason Cater,�Derek Neighbors,�Bajusz Tam�s
Bajusz Tam�s (btami) asked whether support for labels would be included in the next release of Reports. Jason Cater (jcater) said he had just completed this, and pointed to a screenshot - "that was created from a dozen-line report file and by telling reports "Avery 5961" (that is the brand/part # of the labels I use)" - "I still have some small polishing to do" .
Later, Jason reported
"gnue-reports
-f postscript -F 'label="Avery 6879"' mylabels.grd - that, boys
and girls, now works. I tested with 3-4 different label part numbers
that I have in house"
. He explained the -F option was the short
form of
"--filter-options == options to pass
to the filter process"
. Derek Neighbors (revDeke) asked
"how are you making the postscript?
ie.. what libraries or such in python are you using?"
Jason
said
"none"
- he had done this all
himself in python. There was general appreciation of both the
coolness of python, and Jason's coding skills.
29. Using other projects' code in GNUe
12�Nov�2002�Archive Link: "[IRC] 13 Nov 2002"
People: Jason Cater,�Derek Neighbors
Jason Cater (jcater) asked "what's our policy about bringing other code fragments into cvs as a module of gnue.common? e.g., I've found a few small scripts that would be handy for me wrt reports" Derek Neighbors (revDeke) said the key requirement was the code "MUST be gpl compatiable - we prefer assignment, but for such things simply being gpl compatiable license would be enough - oh and courtesy says ask original author if its ok" . Jason noted it was under the normal Python license - "it's one of those things, it's simple enough I could reimplement, so no way I would require an end-user to do - but its feature-complete, stable enough for me to prefer to grab his" . Derek noted that "The License of Python 2.0.1, 2.1.1, and newer versions. are GPL compatiable - from the GNU site" . Jason said "I'll drop this guy a line and ask for his blessing - it's not like I want to publish the code as my own :) - just keep users from needing to install yet another thing" . Derek suggested "i would jsut leave the copyright headers as his" .
�
�
�
�
�
�
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. |