| � | ||
|
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 |
"I was just thinking about reports - I think we should randomly insert pages in reports with the caption "This page intentionally left blank" - what do y'all think?"
Table Of Contents
Introduction
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. Links between GNUe and DotGNU
25�Apr�2002 (6 posts) Archive Link: "[Gnue-dev] Re: [DotGNU]GEASv2"
Topics: Application Server, Common
People: Andrew Mitchell,�Gopal V.,�David McWherter,�Reinhard M�ller,�Daniel Baumann,�Derek Neighbors,�Asif Ali,�David Sugar,�Dacid Sugar,�Jason Cater,�James Thompson
On #phpgroupware, Andrew Mitchell (ajmitch) suggested "we should try get more discussions between dotgnu, gnue, and phpgw? :)" , suggesting "what do you think of a list for discussing cooperation between projects? cos i know that gnue & dotgnu could share a lot, but don't speak much :)" Gopal V. (t3rm1nat0r) suggested "a group IRC meet on this" . Andrew said he had seen David Sugar (dyfet) "(GNUe person & DotGNU lead dude) on irc the other day" . He added "norbert & barry also know how i feel about this, i'll try & get hold of them too" . He suggested getting together "the webservices people & other interested dotgnu members" . David McWherter (dtm) said there had been a previous meeting, but "it was relatively brief and inconclusive except that for the ideas that phpgw should be ported to gnue, and/or phpgw should work alongside gnue via something like xmlrpc/soap." He noted "gnue intends to at least create its own core groupware - because gnue's architecture is apparently highly robust and complete, because they have much higher level enterprise needs than phpgw's current workgroup-oriented target, and because phpgw is tied to implementation specifics such as php" . Andrew felt this made it even more important "to get this crap sorted out before everyone goes off in their own incompatible direction :)" . David McWherter agreed, but said he believed "mdean and derek will do so" .
Continuing on #gnuenterprise, Andrew said "from what i know, an appserver is popular in webservices - see zope for example - GEAS could be used in that regards, if we're allowed to make it generic enough for webservices (i think it should be)" . Reinhard M�ller (reinhard) said his preference was "design it like we need it for gnue - and if we have to extend it for dotgnu then see if it's worth - imho we have defined our primary goals like stability, speed, etc - and i'm not willing to give up any of these for compatibility for something not our primary goal" . Andrew felt "we shouldn't need to with a good design :)" David McWherter believed that "if a major GNU project such as dotgnu needs something it can reasonably deliver, such as an app server, then I think gnue should and would be willing to devote priority to meeting its needs." . Reinhard agreed, but commented that "i've never seen a statement less specific than "it has to be more generic" :)" . Andrew accepted this point - "that's why we want to find out what the needs are first ;)"
Later, Gopal (t3rmin4t0r) asked "so where does the RPC come in ?" Andrew quoted from the documentation - "Several GNUe tools require a platform- and implementation-independent means of communicating with other GNUe tools" . Gopal asked "how can I use gnue as of now for DotGNU ?" Andrew noted that "we're redoing geas, rewriting it in python instead of C" . This was "why i want input now, during the design stage :)" Gopal went to download the GNUe CVS for a look-see, although Andrew cautioned that the Application Server in particular, like parts of DotGNU, was not really usable yet.
David McWherter concluded "so i guess the primary result is that dotgnu wants an app server, so gnue has the option to jive its priorities with that." Daniel Baumann (chillywilly) said "we need another meeting of the minds or something" Andrew said "i was mainly wanting to prod them into looking at gnurpc and geas since that is where the most overlap is" . Later, Derek Neighbors (dneighbo) confirmed "i THINK unless things have changed - 'their' rpc stuff is gnurpc - which is what is in our cvs :)" . He added "to my knowledge david sugar, bradley kuhn, myself, jason and others had a meeting on this - it was determined we would all use XML-RPC to interoperate for right now - and that we would investigate RPC abstraction first in python - and if success was found - that dotGNU might look at making a portable implementation of that" .
On the mailing lists, Asif Ali reviewed Issue�#19, Section�#1� (28�Feb�2002:�GNUe Application Server (GEAS) version 2 Discussion) for possible use of the GNUe Application Server (GEAS) with DotGNU, saying that he felt "the challenge is to support the two track approach and loosely coupled objects's performance tuning and transactions over distributed architectures" . He said that he didn't think that GEAS version 1 was suitable for use by DotGNU, and "unless goals arent well defined.. ..GEASv2 might also might turn out to be a disaster.." . Andrew Mitchell asked Asif to explain his concerns.
Asif said his first issue was the use of CORBA, which he felt would be tough to implement, and the "Use of other RPCs for communication" . Reinhard M�ller said that "As the new GNUe Appserver will use the GNUe Common Library, different communication means will be usable, like XML-RPC." David Sugar also felt CORBA would be a mistake, but "if they could build the server so that it can use a plugin/wrapper for RPC services then it may not be so bad, because one might then be able to select at compile (or runtime) which RPC mechanisms to support, and which not to, based on your target use. To do that is not impossible, but requires thinking a lot more about the internal organization and abstraction between what the RPC expects and how the service calls are implimented." .
Asif was also concerned about "Support for both DotGNU based components (assemblies), webservices and java based components for reusability of objects at runtime." He explained that he saw a typical enterprise application as being "a mish-mash of (a) DotGNU components (class libs) in the form of assemblies (b) loosely bound components like Webservices (c) EJB's if we are adding direct support for Java based components" such as Enterprise Java Beans - "if Java is implemented in DotGNU and bytecode generation is also possible as an added addition to IL..then (c) makes sense." . In this scenario, "object reusability and distributed transactions across different types of components becomes very important." This was an issue that Microsoft .NET did not seem to be addressing. He would start to document some ideas on what a Application Server for DotGNU would need, to see how this fitted with what GNUe were already doing. David Sugar felt that bridging "a Python app server to Java might be interesting and challenging. Could GEAS invoke something like a bean?" .
Earlier, David Sugar said he believed "there is a natural synergy between" DotGNU and GNU Enterprise. "DotGNU could provide the framework and vehicle for extending GNUe into a webservice, and I think this is some place GNUe will need to eventually go. Many of the things in GNUe, like invoice and supply chain management, general ledger, report generation, etc, are not "sexy" applications, but they are things at the core of and required for any enterprise, and being able to provide such services thru the web as well as locally could prove very useful" , especially in the context of Business-to-Business (B2B) applications.
on IRC, Daniel asked whether Asif was looking to "go a step further and make the app server support various environments?" Andrew suggested "for a DotGNU-GEAS object loader, we could wrap some of pnet/SEE in a shared lib & python code, to make stuff accessible" . Daniel said he had been thinking "we were going to do methods in other langs and that would the extent of it - but that proposition is intersting..." Jason Cater (jcater) "fears another case of over-complicating things" . Andrew clarified that this would not be part of the core GNUe Application Server - "this'll be bloat we add later to a sleek, clean core :)" . He felt that "with a decent structure they can work on that stuff while we get the base working right :)" . Daniel said "we should keep things in mind for reusability, but I don't want to freakin' make it the focus" . Andrew said "i just wanted to keep these nice people in mind :)" Daniel agreed.
The next day, Gopal asked about "XMLRPC support" . James Thompson (jamest) explained that "gnurpc (working name) is an abstraction layer in our communication protocols" , written in python - "that's where our usage of xmlrpc is being coded" . Gopal hated CORBA, and wasn't keen on SOAP - he "prefers XML for everything" . James said "xml is nice but it's a little heavier on the wire IMHO - but we're all about options and xmlrpc is an option :)" .
2. Using XML for GNUe Class Definitions
25�Apr�2002 (2 posts) Archive Link: "[Gnue-dev] GEAS (v2?)"
Topics: Application Server
People: Jason Felice,�Reinhard M�ller
Jason Felice asked "Why are we not using XML" for GNUe Class Definition (.gcd) files. Reinhard M�ller said "We were looking for a file format that's easy to author. Writing XML by hand is not efficient. However, as soon as we will have a visual designer, the file format will be irrelevant. We will probably store the object definitions in the database and use XML to exchange them" , as proposed in Issue�#19, Section�#8� (2�Feb�2002:�Object vs Relational Databases)
3. Problems with triggers in Forms
24�Apr�2002�Archive Link: "[IRC] 25 Apr 2002"
Topics: Forms
People: Derek Neighbors,�Jason Cater
Derek Neighbors (derek) was having problems with the PRE-COMMIT trigger in Forms. He was trying to use it to pass the primary key from the master table to the detail table, but "it definitely is passing null's" . He was also having problems with the "PreCommit and PreInsert" triggers, and "autoFill still isnt release reasdy :) - though jamest swears it works for him" . The documentation on triggers had just been updated a few weeks ago, so some of these latest triggers were still undocumented as of time of writing. Jason pointed out that "triggers were not "supported" prior to this next release - and most of the trigger code has been recently added" , although "we had "triggers" of some fashion or another the last few releases - but they were "proof of concept"" . He confirmed they were looking to do a new release of Forms soon - "and designer and reports and common" .
4. Record locking in Forms
24�Apr�2002�Archive Link: "[IRC] 25 Apr 2002"
Topics: Forms, Common, Application Server
People: Daniel Baumann,�Jason Cater,�Andrew Mitchell
Daniel Baumann (chillywilly) asked "how does forms handle concurrency right now? like if 2 dudes were running the same form and modifying the same info" ? Jason Cater (jcater) said "we would have the database lock the record being modified" . In n-tier, where Forms was talking to the Application Server (GEAS) rather than directly to the database, it would be up to GEAS to do locking. Daniel agreed - "yea, geas should support an object locking mechanism like in the "Object" interface" . He wondered "what does the other guy see who doesn't lock the db? - he gets readonly values?" Later, he added "how much simultaneous access stuff have you guys tested? - do you get a phantom read? do you step on each others toes? what happes?" Jason said "it'd be a standard database error that gfclient would display - something like "Unable to reserve record for update" would popup on your screen" . However, you should still be able to "read the record if it's locked" . He explained "forms will (when we finish it) try to lock the record on the first keystroke you make that would modify it - if it can't lock then it wouldn't let you modify the record and issue a warning" . Daniel liked the sound of this.
Earlier, Andrew Mitchell (ajmitch) asked what "if the db driver is too crap to provide proper locking?" Jason felt that "if someone chooses to use a crappy database - well, then, that's their decision" . Andrew asked "is there a flatfile driver yet?" Jason said "no - but it's needed" , adding "I'd like to get one whipped up by the next-next release" .
Daniel suggest that database drivers should emulate behaviour like row-locking "if the db does not support it" . Jason couldn't see how that would work unless "they are on the same machine running under the same session" . Later, Daniel felt "now theoretically shouldn't a db abstraction layer support all features and provide emulation for those that don't support things or do you go with the common denominator? where do you draw the line?" Jason agreed - "for the most part, it's a common denominator - but all dbms' should support a minimum of features - if not, then they should be renamed to a "relational file system" - and not a "relational database"" .
5. Debian packages for GNUe
26�Apr�2002�Archive Link: "[IRC] 27 Apr 2002"
People: Nick Rusnov,�Jason Cater
Following on from Issue�#24, Section�#2� (3�Apr�2002:�Debian packages for GNUe and DCL) , Nick Rusnov (nickr) said "I have a few minutes to work on the packages for gnue now - I was wondering what packages base depends on? or recommends|suggests" . Jason Cater (jcater) said that "gnue-common" was the effective "base" package - it "requires: python2.1, python2.1-egenix-mxdatetime" . He asked "um, what's the definition of "suggests" ? and "recommends"" ? Nick explained "Suggests are things that it'd be nice to have but doesn't need to be useful - recommends are things that are not required to use it but make it much better - like recommends would be whdere you put db drivers" . Jason thought that "python2.1-mysqldb and python2.1-psycopg should be in recommends" . Nick confirmed that GNUe Common could "build correctly without them installed and still support them if they are installed?" Jason thought the egenix-mxdatetime dependancy was more problematic, as "datetime will be "required" for gnue-forms - but "recommended" for common - as I know forms "needs" it - but I guess you're right, common doesn't" . Nick suggested "it can still depend on it without having a build-depend on it." Jason said that "gnue-common is a pure python play, so I don't think it "needs" anything but python to "build"" .
Nick asked "is there any way to prevent setup from installing etc/ into etc? I can't install the sample conf files into /etc if eventually there'll be a debconf wizard to set that up or something - I have to put them in examples/" . Jason said "not at the moment" , but "maybe you need to tell us what you need to do it "properly"" . Nick suggested "if setup stuck the etc/ stuff into etc/gnue/ I could just mv that down to usr/share/doc/gnue-common/examples/ - since you're using disttools it makes things really easy otherwise. As long as the prefix thing works correctly. Or if it didn't install etc at all that'd be easy too" . He confirmed he was using python version "2.1, snice that is the debian default I believe. or rather the 'official' version" . Jason said "it's a good "safe" version too - that's what we all do development with" .
Nick noted that "it sticks everything in usr/local" and asked "do you like hardcode usr/local into it?" Jason said "that's settable - although everything is still relative to a base directory i.e., gnue/ - I can hack around that if this is really causing a problem" . He asked "how do you want it installed - and I'll see what I can do real quick" . Nick said "alll the python libs should go in usr/lib/python$VERSION/gnue/ - all the images and stuff should go in usr/share - the docs and such can go wherever, I'll just move them" . Jason noted "the first one we fought hard to stop our setup from doing - as that's a bad no-no" . It was "great, for debian :) but we are more than debian - that's where our issue comes from" . Nick wasn't aure why - "makeing it fhs under the prefix would solve a host of problems with me but shouldn't really cause any for other platforms" . Jason suggested "I'm thinking of having a site.cfg that the scripts need to know the location of but it would contain pointers to the other directories" . Nick said he would then need to tell the debian packages where to look to find this file, but that should not be too bad. "once this is solved, the rest is easy" .
Later, Jason asked "do you have a build/install script or something that calls our setup.py?" Nick explained "from a makefile I call python2.1 setup.py build and then later on call install --root ./debian/build --prefix '/index.html'" . Jason said he had amended the code so that "in between the build and install parts a site_config.cfg file is created" . If an external process such as the debian installer added path names to this file then "the setup.py install (with a --cfg-path setting) will copy this file - and the tools will respect it" . This "gives you a way to make the tools respect any moves you do" .
6. Database drvier problem with Jump To Record
26�Apr�2002�Archive Link: "[IRC] 27 Apr 2002"
People: Bajusz Tam�s,�Jason Cater,�Harald Meyer
Bajusz Tam�s (btami) reported problems with the 'jump to record' using Interbase - "i'v tried it with pygresql too" , and Harald Meyer had reported the same problem with MySQL. Jason Cater (jcater) explained "we wrote all these drivers based on a Python DB-SIG standard - we quickly found out that they all behave differently against the "standard" which is why we see these quirks - so while it's easy to say "yeah, it's gnue's problem" (which is partially is) we are the first app AFAIK to actually use all these "standardized" database drivers side-by-side" . He said "as soon as I get a chance to test I'll see if I can find out the issues with those two drivers" .
Later, Bajusz suggested "what do you think about a new lastrecord atrrib in the GDataObject ResultSet class ? maybe it would be a better workaround then owerriding the _loadNextRecord in many drivers" . Jason said there had been a reason why they had not done it that way, but he could not remember why. Bajusz explained "then _loadNextRecord would be called only when lastrecord=0 in first/last/next/prev/set record" . Jason agreed - "at first I was afraid of a performance hit - but that could be a performance gain" . He would "try to get to it tomorrow if I can" .
7. Toolbars and UI in Designer
26�Apr�2002�Archive Link: "[IRC] 27 Apr 2002"
Topics: Designer
People: Derek Neighbors,�Jason Cater,�Christian Selig,�Nick Rusnov,�Christopher Selig
Christian Selig (sledge_) said he would like to get rid of the 'toolbar' in Designer. Derek Neighbors (derek) disagreed, but "i do think its ok to make an option in gnue.conf" . Jason said "I don't necessarily like it either - but I want a complete UI plan before we do anything like that" . Christopher said that the toolbar just "provides a second functionally identical way of achieving something (in that case, changing certain values) which confuses users" . Derek disagreed - "its a matter of preference - its nice to have more than one way to do something - as long as all the way s do the same thning. I have NO problem making it optional - BUT to remove it will have 50% of the people asking why we dont have a toolbar" . Nick Rusnov (nickr) felt "menus are confusing - seriously, I don't understand why they are so widely adopted." Derek said "i think OPTIONAL is the right answer - as it give EVERYONE what they want - if you dont like the tool bar simply remove it via an option - hell if enough people are anti toolbar you could even make that the default" .
Christopher clarified that he wasn't referring to "the toolbar which includes the little icons!!!" , but the "thing which is beneath the actual form layout, letting you change name, x, y, w, h" , which was referred to as a 'toolbar' in the source code. Derek said "ah dood, you have me worked up over nothing :) - i fully agree with that one :)" Jason said "I still want to make it OPTIONAL as I rely on that - I HATE having to have a Property Editor up just to change common attributes" . Derek agreed, but said "it wouldnt be bad if you made say F11 or F12 toggle between the form and the property editor - as then you can have one on top and one on bottom" . Christopher pointed out that "a good drag&drop (think: delphi) would render that ToolBar useless and is way more intuitive" . Derek said "you can do some of that now" . Jason clarified that "I have no intention of making major UI changes prior to a release and without a cohesive plan. Our UI was certainly hacked together and it needs to be revamped but I don't want to hack away hacks" . Most of the drag and drop functionality was already there, but wasn't very responsive, due to the use of wx - "but the advantages we gain currently outway the disadvantages" .
8. GNUe Document Store
26�Apr�2002�Archive Link: "[IRC] 27 Apr 2002"
Topics: Doc Store
People: Nick Rusnov,�David McWherter
Nick Rusnov (nickr) said that his Document Store proposal, as discussed in Issue�#20, Section�#5� (8�Mar�2002:�Document Management for GNUe) , was "Pretty dead in the water - no demand, no assistance, no motivation" . David McWherter (dtm) said he had "found trivial document management" project called Tavi - "we integrated it into phpgw" . But "it's just for text and html - it does revisioning and stores in sql" . Nick said he was "thinking of restructurling" his proposal "to be more like a sort of immutable CVS of sorts - well not exactly - but something that more addresses my personal needs." However, "I should lay out plans for an organic document system too" .
9. DCL structure and wish-lists
26�Apr�2002�Archive Link: "[IRC] 27 Apr 2002"
Topics: DCL
People: David McWherter,�Jeff Bailey,�Nick Rusnov,�Jason Cater,�Daniel Baumann
David McWherter (dtm) kicked off a discussion on "basic DCL usage" . Jeff Bailey confirmed he had produced a new debian package for DCL, "waiting for woody to release. I don't want it in woody" .
David pointed to his diagram of "my impression of how dcl's static structure is organized - i welcome anyone to clarify or correct that impression" . He explained "the "type of hierarchy" is my improvisation - it's a little abstraction layer to help think about it - it may also serve in redesigning DCL to be more flexible. I would like to propose that we focus on those basic types of hierarchies.. in other words, create high level flows or whatever. and then allow the configuration of arbitrary amounts of component hierarchies. In other words, to not have statically defined "domain" and "project" and "WO" concepts and to instead be more flexible for organizations who have higher levels of hierarchy, or finer grained hierarchy - like a corporate conglomerate with multiple business units - or for a workgroup that wants to use one DCL installation to manage their business and multiple related businesses and each of their personal lives." . Nick Rusnov (nickr) asked "has the user interface been abstracted more? It seems ilke it was very ummm crosslinked" . David agreed - "it feels sometimes like a labyrinth of concentric circles - it's not bad, especially coz there are always the high level menus available - i think it's done for convenience. it's a deep app" . Nick said he would like "easier interaction with the database in an abstract way - like so additional apps could be written as sort of frontends to it" .
Later, Jason looked at David's table, and said "it looks ok to me - I do agree w/the defaulting - that's one of the oddities of dcl imho - in that, stuff that seems like it should default doesn't" . David asked "what do you think about the idea of redesigning DCL to not be static around its organization? and to instead just have types of hierarchies which are arbitrarily configurable?: do you dig?" As a non-coder he wasn't sure if this was sensible, but "all i know is that dcl doesn't scale organizationally" Jason said his "knee-jerk reaction says that it sounds great - but not sure how much recoding that'd take" . David suggested "that its current static structure should be the 'default' config for my proposed dynamic structure" , but "It'd be really, really cool if DCL could have sort of dynamic organizing like that. See, i want one dcl installation to serve multiple businesses, plus the personal lives of the individuals. So this would require that each person has their own products, departments, etc. phpgw has at least a concept of that, in terms of their "global category" - so maybe dcl could implement it literally as a "global category" from phpgwapi - or maybe that would require more fully porting dcl atop phpgwapi, rather that its current state of nestling within or next to it" .
Earlier, David asked "does anyone here know if DCL domains create a separate namespace for usernames? is there any ACL there, or is there one authentication base which can access all configured DCL domains?" Daniel Baumann (chillywilly) said "and as far as security goes we would be better off for an infrastructure for all of GNUe" . He thought "Role Based Access Control" (RBAC) looked nice - "it's what SE Linux uses" .
David concluded that the discussion had been "*tremendously* valuable for me as a NON-CODER to have any of you people validate my ideas, or at least to look at em and to not discount them" .
10. Two-tier and n-tier GNUe
28�Apr�2002�Archive Link: "[IRC] 29 Apr 2002"
Topics: Application Server
People: Matthew Emmett,�Derek Neighbors
Matthew Emmett (memmett) asked "is there a "getting started" guide or something similiar i could look at? " Derek Neighbors said "its called this irc channel :) - get the snapshot or cvs - get the dependencies - and start going to town - ask here if you have questions :)" . As of time of writing, he suggested "ignore application server and gcd files altogether for right now - GEASv1 is being replaced by GEASv2 - so for now i suggest avoiding it, if you are wanting production stuff - and look at doing 2 tier for now - and when new version of GEAS is ready then upgrade to it" . Matthew said "ok.. so i'll just make a db normally and then use forms and designer to access it 2 tier for now" .
11. Documentation standards for GNUe
28�Apr�2002�Archive Link: "[IRC] 29 Apr 2002"
People: Derek Neighbors,�Peter Sullivan,�Nick Rusnov
Further to Issue�#25, Section�#9� (11�Apr�2002:�GNUe Documentation) , Derek Neighbors (dneighbo) noted "there is now a docbook channel here on openprojects - and the maintainer (nwalsh) resides there so if you have docbook problems in teh future probably a good place to seek help" . Peter Sullivan (psu) asked "would there be any point in converting our docbook-sgml docs to docbook-xml docs?" Nick Rusnov (nickr) felt "xml is easier to work with" . Derek thought "there is benefit - i dont think it would be a 'ton' of work - as iirc sgml is more strict that xml - so there probably isnt a 'ton' of change to the source" . Nick said "its more strict in a different way" . Derek said the down side of using Docbook XML "is i do not believe the xml/xslt combo is working all the way - i believe things like PDF etc are still not working for Docbook, but are close" . He "needs to find a channel" with xslt experts like Doug Tidwell or James Clark.
He had had Simple Docbook recommended to him as an alternative to the full Docbook markup, "which is 100% compatiable if you ever wanted to go out side of simple docbook" . Nick said "I was advocating a simple markup language that didn't use <> tags - like a extended plaintext format" . Derek said he "wouldnt be opposed to making a python converter i.e. so that one can write docs in simple text" and then convert them. Nick advocated POD - "the perl document format" . Looking into Simple Docbook, Derek noted "gack simple docbook has 106 elements - i was thinking more like under 50" .
Derek suggested "i think i could take the list of elements in simple docbook - print them out - and go through and pare it down to a small subset we would actually use (probably about 30) - and then that could be what we make supported for this pod format - and it would basically just convert a text file into docbook xml" . However, this "seems like such a waste though - why can not someone make a good doc tool?" . Another option would be "to get staroffice/abiword to work i.e. if we defined 'styles' for those" . Nick felt "well writing an xslt thing to convert abiword xml docs would be easy - abiword supports all the 'logical markup' we need - its just a pain to use it :)" . Derek said you could use xslt to convert back and forth from abiword XML to Docbook XML, "but would have to abide by a certain stylesheet" . He "just doesnt want to spend time donig this sort of thing - it would be nice to have a cohesive doc solution though"
12. Creating Forms definitions without Designer
28�Apr�2002�Archive Link: "[IRC] 29 Apr 2002"
People: Matthew Emmett,�Derek Neighbors
Matthew Emmett (memmett) asked "is there a forms reference somewhere (so i can create a form by hand) ?" Derek Neighbors (dneighbo) said it was "/GNUe/in_gnue/forms/doc/index.html" , but asked "any reason you dont wnat to use the designer ?" Matthew said his "x11 forwarding is busticated" , which Derek thought was fair enough. He commented "emacs works fine - we made forms for over a year this way :)" before the visual Designer had been written.
13. Curses implementation of Forms for non-GUI clients
28�Apr�2002�-�29�Apr�2002�Archive Link: "[IRC] 29 Apr 2002"
Topics: Forms
People: Matthew Emmett,�Derek Neighbors,�Jason Cater,�James Thompson,�Gontran Zepeda,�Arturas Kriukovas
Matthew Emmett (memmett) asked "do i need to install a python ncurses module for -u text or -u pytext to work?" Derek Neighbors (dneighbo) said "um i think we have moved to ntti - the curses implementation is currently broken iirc - but its darn close to working again" . He explained "we hvae tried two different curses implemenations and are moving to our third - original was pyncurses - which is -u pytext - and then i think we went to native python curses which was -u text - now i think we have adopted ntti and i am not sure what -u it is" .
Matthew asked what version of python was best for GNUe Forms. Derek said "i had unicode problems with 2.2betaX but others didnt get same issue - so its probably safe - we generally recommend 2.1 if you dont have a python yet as thats what we develop on" . Jason Cater (jcater) said "2.2.1 should be safe - but I'd avoid 2.2.0" . Derek said they were trying as far as possible to support all versions of python "2.x or greater :)" .
Matthew said it "looks like i'll need to install the "nstti" (not so tiny text interface...)" . Jason warned "that is no where near usable" as of time of writing. "we are actually patching nstti to add more functionality to it" and it would hopefully be included in the next release but one. It was not "far enough along" to be worth filing bugs against yet. Derek suggested "jamest: what would be nice is if you could flesh out the TODO's to get nstti working and file them as workorders in dcl - or if you can just jot them down in a txt file and email me - i will start a 'project' and create the work orders so people can monitor progress" . James Thompson (jamest) said "it's a shell - basically enough code there to say this _might_ work" . He explained "we're having to fix up nstti as we go (in fact it's in cvs on www.gnuenterprise.org with authors permission)" . Derek said "that is cool, but i imagine you have or will have a plan of attack - if you can get that to me in text file i can start some 'management' of it :)" , adding it as a product in DCL and "maybe i can find someone to write it :) - maybe even me" , or else Arturas Kriukovas (Arturas) - "it would be nice to give him specific tasks" .
The next day, Gontran Zepeda (gontran) noted "so pyncurses hasn't been maintained in over a year on sourceforge, is there any use for it in gnue (anywhere) currently? or what was the vision for it's inclusion?" Derek Neighbors (dneighbo) said "the maintainer of pyncurses actually was doing gnue developemnt for a bit - he stopped doing gnue and pyncurses at same time - we were going to 'adopt' it, but then found native curses in python and switched to that. So we ahd -u pytext and -u text for ui modes. Recently we have found nstti which is better than both. It is unmaintained. We dopted it and its inour cvs tree. jamest almost has it working with forms - probably not this releasse but next" . This would become the default text UI, "however at anypoint someont could revive the pyncurses or native curses drivers" .
Gontran asked "would there be any, ahem, strategic advantage to either pyncurses or the native drivers?" . Derek said "well pyncurses lacked to much - and was a dependency and not maintained - native was good (no dependency) but had very limited functionality - nstti was WAY more advanced so it is less work to maintain it and add what we need" . However, "we certainly would not prevent anyone and would encourage anyone to write the drivers for pyncurses and/or native - as choices are good :) - though admittedly it woudl seem like a waste of time" .
14. GNUe as a Rapid Business Applications Development toolkit
28�Apr�2002�Archive Link: "[IRC] 29 Apr 2002"
Topics: Why GNUe?
People: David McWherter,�Derek Neighbors
David McWherter (dtm) asked "does gnue intend to become a RAD environment?" . Derek Neighbors (dneighbo) said "it is already - it does not want to be Delphi, powerbuilder, VisualBasic - it wants to be a Business RAD tool" . David clarified "what i meant to say was, does gnue intend to be a RAD for newbies" , like LAMP (the generic term for using Linux, Apache, MySQL and PHP - "you know, basically throwing something together quick and dirty but stable" .)? He was "trying to envision phpgw's long term relationship toward gnue" . Derek said his view was "that GNUe Tools are RBAD = Rapid Business Application Development tools - geared as much towards :business/system analysts: as programmers. i.e. if you can understand teh structure model of your data and can define what 'rules' you want you should be able to make applications in GNUe w/o beign a hard core programmer - much the way our analysts today can open up Excel, do some spiff work sheet functions, maybe even make some macros adn do some pretty cool stuff - but if you asked them to 'program' something they might laugh at you" .
Later, after a long discussion about sashxb as an alternative to GNUe, he added "GNUe's power is not ONLY in fact that its xplatform, XML based UI - we are starting to see these in droves - its REAL power is its data handling - fact i can make a master detail form that is xplatform in under 5 minutes - and all databinding is handled - no SQL no anything" . He noted "most of these other tools dont even think about making widgets talk to a database - much less complex stuff" . "for us data aware isnt an 'afterthought' it wsa the REASON to write GNUe - so why we dont have all the whiz bang pretty widgets to say write and ftp client - we make it easy to write a dataaware business appliction :)"
15. GNUe and PHP Groupware
28�Apr�2002�Archive Link: "[IRC] 29 Apr 2002"
Topics: Customer Relations
People: David McWherter,�Derek Neighbors
David McWherter (dtm) asked about "writing groupware with gnue?" Derek Neighbors (dneighbo) said "you define GROUPWARE much differently than mdean and myself - to us groupware is a server thing not a client thing - i.e. we would expect it to be no problem for someone to extend say evolution, phpgw etc to use new items in gnue groupware - we do NOT plan on making clients - though forms and geas would be able to hook into the serices just like anyone else's clients" . He noted that "there are some prexisting specifications like iCalendar,vCard, LDAP and such that if we reused properly could be used by existing clients almost untouched - on other pieces we would make the service and pick client of choice and implement there or convince them its good for them to implement" . He noted that a "contact application (CRM) is not groupware :)" per se, but "groupware services would make it BETTER" . He would be keen to extend the current PHP Groupware cliets if possible - "the point is not to make clients from scratch :) - too many exist and we are busy :)" .
David asked "so in other words do you want to reimplement the concept of" PHP Groupware's API (Application Program Interface)? Derek said "i dont know enough about phpgwapi to say if thats what im proposing :)" . David said "i know that 1) phpgwapi intends to be a php-based RAD 2) mdean severely doubts or discounts its robustness, and he knows it well 3) other people do take it seriously although i'm not sure if they fully understand it, but for example savannah.gnu.org wants to port all their services atop phpgwapi." Derek felt that "to me GROUPWARE is not something you use to build savannah :) - imho GROUPWARE should not be a RAD - it should be services" . However, "mdean is the groupware mastermind though :) so i defer all to him :)" .
16. i18n and translating error messages
29�Apr�2002�Archive Link: "[IRC] 30 Apr 2002"
People: Arturas Kriukovas,�Bajusz Tam�s,�Reinhard M�ller,�Derek Neighbors,�James Thompson
Arturas Kriukovas (Arturas) was starting work on some i18n code, which would be needed in all parts of GNUe. He asked "how should i call file that will be imported into EVERY .py file? i thought about something like GImport.py (in /common/src)" . Ideally, he wanted to "write it once in some main, basic file, that is imported in EVERY other .py file" but "i haven't found such file - so i create GImport.py and import it everywhere - this file will have 'gettext import...' and some other commands can be added" . Bajusz Tam�s (btami) asked "isn't the GBaseApp.py the main basic ?" Arturas said there were some files, such as "GDebug :(" that didn't include it. Reinhard M�ller (reinhard) said "it's a matter of taste - but I don't like those everywhere-included files as they tend to become bigger and bigger" . He felt "it's not clear what really depends on what" . Arturas said he wasn't keen either, "but sometimes it's (?) convenient" .
Bajusz asked Arturas "have you read the jamest ideas " about having error messages "loading when program starts" ? Arturas asked "do we have so much translatable strings in .py files? at least in /common there are not 10Mb :) - i don't believe loading will take a lot" . He asked "what is the principal difference between dict and _("string") ? why dict is cheaper?" . Bajusz said it was down to "exec time" . He didn't "i dont know the whole size of msgs" but "in Abiword this is some KB" . They decided to ask James Thompson (jamest).
Later, Derek Neighbors (dneighbo) suggested "before you commit anything talk to jamest/jcater" . His understanding of the i18n functionality that Arturas was adding "is that it would be part of GBaseApp - which is an object that can be available to virtually anything - just because its not in GDebug doesnt mean it cant be" . James confirmed he was talking to Arturas about it.
17. Using XML-RPC with GNU-RPC (GNUe Common)
29�Apr�2002�Archive Link: "[IRC] 30 Apr 2002"
Topics: Common
People: Reinhard M�ller,�Jan Ischebeck,�Christian Selig
Jan Ischebeck (siesel) confirmed that there was no debian package for the xmlrpc library needed to use XML-RPC as the remote procedure call transport mechanism for GNU-RPC (GNUe Common). Reinhard M�ller (reinhard) said "did you look at the possibility of using the library that is in debian?" He thought it would be good if the basic GNUe system only had dependancies that were in the common distributions, such as Debian woody (3.0) and RedHat 7.7. Jan said there was an alternative XMLRPC library that was available in Debian woody and which was under the GPL (GNU Public License) and was faster, but which was more difficult to set up - "the client is working ok, but the server is a bit difficult" . He noted "the orignal server from the py-xmlrpc package (the one in debian) is written i pure c with python bindings. The problem is, that the name of all methods has to be registered in an array accessible by the c part. i.e. no way to do a real dispatch."
Later, he noted "eeh, there is a mistake in the README, there is no debian package. (python-xmlrpc is not the right one) - it's called differently" . Christian Selig (sledge_) was surprised that "there are two xmlrpc library for python in debian?" . Jan confirmed "python-xmlrpc is the wrong package. you have to download xmlrpclib.py from pythonware." Christian asked "why not use python-xmlrpc? (noi)"
18. Extent of GNU-RPC functionality
29�Apr�2002�Archive Link: "[IRC] 30 Apr 2002"
Topics: Common
People: Derek Neighbors,�Jan Ischebeck,�Derek Neighors,�Christian Selig
After a discussion about preferred XML editors, Derek Neighbors (dneighbo) commented "i would imagine you wouldnt need much xml for grpc - as the objects are not in xml - i.e. it should be fairly generic wrapper - unless things have massively changed" . Jan Ischebeck (siesel) said "Its not about moving objects, just about describing a way to contact them. If a RPC method returns an object, the object is stored on the server. and an handle is send to the client." He had "thought of using the grpc package to check which methods can be called and which not..." Derek said he hadn't anticipated supporting "all features of every rpc" . Christian Selig (sledge_) agreed - "if someone needs specific features, he won't be interested in the other protocols anyway" . Jan took the point, and said "I try to get the things running as fast as possible (and with minimal efford) and would be happy about comments after the things are checked in."
19. Query mode in Forms
29�Apr�2002�-�30�Apr�2002�Archive Link: "[IRC] 30 Apr 2002"
Topics: Forms
People: Matthew Emmett,�Derek Neighbors,�Derek Neigbors,�Jason Cater,�James Thompson
Matthew Emmett (memmett) asked "using forms, i can insert new records and everything is cool, but when i reload the records aren't displayed (i can confirm with psql that they were in fact inserted)." Derek Neighbors (dneighbo) confirmed that forms opened in entry mode by default, but you could run a query using f8 and f9. He explained "ok the way it works is we have inline query building - so if you hit F8 then go fill out data in your fields then hit F9 it does a select that uses those values in the where clause" . He confirmed "there is a way in the datasource to make it AUTO query at start up - in the datasource tag you put prequery="" - HOWEVER i think its broken right now in cvs (or was a few days ago)" . Forms could cope with large numbers of records "as we have cache="" which tells how many records to keep in memory - i think the default is like 5" . He suggested "you play iwth the 'prep query' F8 and 'exec query' F9 - you can do some cool stuff - you can use the tool bar buttons as well or menu items you arent forced to use the F keys" . Matthew asked "do the "wildcards" depend on which db driver i'm using?" . Derek did not think so. Natthew said "it'd be really cool if we could put regexp's in the fields, but i guess that isn't standard SQL.. oh well" .
The next day, Derek asked how queries on Master-Detail forms worked - previously this had not been supported at all. He had expected that if he put conditions on both the Master part of the form and the Detail, that both conditions would be applied. However, "what it did was query just the entire detail table (regardless of master) - is that what is 'expected' ?" . Jason Cater (jcater) said "I do know query by detail is not supported - we haven't implemented it yet" . Derek said "it used to give you an ERROR if you querired by ddetail - not an error but a message saying 'thats not supported' - if its not supported we need to reinstate the message imho" . He was surprised it had gone, "as prequery and this error message were two things jamest added orginally from his users complaints" .
He had "started to redo prequery as WE REALLY need it - and it should be default behavior (imho) as its a major user stumbling block - EVERY user that comes inhere with a new install asks how come i cant see my data :)" . James Thompson (jamest) investigated, and concluded "wow - i guess it is borked - i can't believe no one complained" . He noted "prequery on datasources does work or all my dropdowns would have broken - it's not displaying though - unless someone did something fancy to make prequery work only with dropdowns which I doubt" . Derek said "thats why it wasnt 'critical' as it didnt break my dropdowns :)" but he would now raise a bug in DCL for both this "and for the 'query detail not supported' issue" .
20. Overview of GNUe
29�Apr�2002�Archive Link: "[IRC] 30 Apr 2002"
Topics: Financials (Accounting), Application Server, Common
People: Daniel Baumann,�Reinhard M�ller,�Derek Neighbors
It was asked if the GNUe tools could be used to build frontends for an enterprise resource planing system (ERP). Daniel Baumann (chillywilly) said "well I think we are sort of an ERP project - we could always use more help ;)" He explained "we are building the tools first...packages are also in parallel development, but that app server is now being redone so package development is sorta at a stand still" , although there was a design for an accounting package. It was noted that in Germany, accounting software has to be certified, which was quite expensive - this might be a barrier to the use of GNUe Financials in Germany.
The next day, Reinhard M�ller (reinhard) commented "i am 100% positive after finishing the financial module we will find someone who approves it in germany very quickly" . He said "if we find only say 20 companies wanting to use GNUe accounting in germany and dividing the costs among them it would be doable" . That was "how free software works imho"
Previously, in response to questions about architetcture, project plans and timelines, Daniel said "well their used to be architecture guides but they are old - forms has a technical reference and user guide - geas is being reworked and a draft architecture giude is in cvs" . Derek Neighbors (dneighbo) said there were "6 or so core folks" doing development "but as of late i think we have nearly 40 people that have copright assignment that can or have contributed on some level - i believe we have several hundred folks following the mailing lists and such - and certainly more nameless ones that keep in touch via GNUe KC" .
Derek said "we will have GNUe Workflow eventually, its not a current focus however" . He explained that the first version of the GNUe Application Server (GEAS) was being re-written - "basically its middleware - in the sense that it provides rpc communication to clients - and allows business logic to sit on it - instead of in the client or as triggers/stored procs in the db. It will also quite likely offer relational to object mappings" . There was also much work going on developing GNU-RPC (GNUe Common).
21. Documenting GNU-RPC (GNUe Common)
29�Apr�2002�-�30�Apr�2002�Archive Link: "[IRC] 30 Apr 2002"
Topics: Common
People: Derek Neighbors,�Daniel Baumann,�Jason Cater,�Gontran Zepeda,�Jan Ischebeck
Further to Issue�#25, Section�#7� (10�Apr�2002:�Documenting GNUe Common) , Derek Neighbors (dneighbo) pointed to a " diagram of common for chillywilly" . Daniel Baumann (chillywilly) said "all we really need is to embed some comments/docs into the code and we can have ourselves api documentation that can be generated" . He didn't "like the fact that in gnurpc we call the various rcp methods 'Interfaces' - we should call them transports or something like that and an interface would be the exposed methods, imho" . However, it would be confusing to change this now.
After midnight, Daniel Baumann (chillywilly) asked "why is there always a proxy object involved?" Jason Cater (jcater) replied "to proxy the requests" - however, this might not be necessary with object-orientated transports - "in corba's case, I think it'd handle the proxying for us" but he wasn't sure. Daniel asked why GNUe Common supported a "connection to a unix domain socket and a tcp/ip socket at the same time?" Jason said "a socket file is faster, iirc - but you have to be on the same machine" . It was "not a big deal providing either option" . The parameters for a TCP/IP connection would be the host name and port number. The ansychat module it used was not standard python - "it's part of medusa - which we may bring into our cvs tree (if licensing permits)" . This was also what "Zope and Webware used" . Jason explained that code like "__name__ = '__main__'" could be used to test whether a module was being run directly "from the command line" or whether it was being called from within another module. Daniel thought this was "a nice way to add text code for your module" . Jason agreed, but said there were other uses too.
Later that day, Gontran Zepeda (gontran) posted a "semi-beautified common.dia" . Jan Ischebeck (siesel) said "cool. I want to have a poster of it" and noted "hey jcater: there is even an bakery on it ;)"
Later, Daniel asked about "this call() method in the xmlrpc driver" . Jason explained "gnurpc supports objects whether the underlying transport does or not. xmlrpc does not - so when an object is being used the server creates the object, but the client creates a proxy of that object (this is the client code in gnurpc, not the actual client app). So when a method is called against an object a string representing that object is passed back and forth via the transport (xmlrpc)" . In general, he felt there was "not much to it" in GNU-RPC (GNUe Common) - "just basically a few methods to say, "what methods do you expose" - you're gonna know more about gnurpc than I here shortly :)"
22. Coding standards for GNUe
31�Mar�2002�-�30�Apr�2002�Archive Link: "[IRC] 01 May 2002"
People: Jan Ischebeck,�Derek Neighbors,�James Thompson,�Reinhard M�ller
Reinhard asked about using CamelCase ("HumpBack") or under_scores in function names. Jan Ischebeck (siesel) said that, as a Java convert, he tended to use CamelCase "but i think both ways are ok. its just important to be" consistent. Reinhard said that the GNU standard was under_scores, but the code for GNUe Forms and Common used CamelCase. Derek Neighbors (dneighbo) said "in code camel case i think is preferred - in table definitions _ is preferred" . Jan noted that under_scores used "one byte more in the code than doFoo (bar, baz).... so the real performance freaks ;) use the last one" . James Thompson (jamest) suggested that, in that case, "1 letter function names rock!" Derek suggested "since common, forms, reports, designer are written - rather than go and and change - lets use what they do" , although he was not "certain what that is" . Reinhard asked about spacing before a function name or between parameters. Derek said he didn't think consistancy here was essential "the important part is the name - as that is what will be 'referenced'" . Reinhard agreed - "iAmHappyWithEverythingYouWant" .
23. .grpc files in GNU-RPC (GNUe Common)
31�Mar�2002�-�30�Apr�2002�Archive Link: "[IRC] 01 May 2002"
Topics: Common
People: Derek Neighbors,�Jan Ischebeck,�Jason Cater,�Daniel Baumann
Derek Neighbors (dneighbo) asked "what is a .grpc file?" He was "just nervous that specs are being made w/o any formal review" . Jan Ischebeck (siesel) said it was "a description of an RPC connection. (in XML)" . This was not a replacement for a .gcd (GNUe Class Definition). Jason Cater (jcater) explained "it defines what methods we want exposed, so each "Server" app will have a grpc file - yeah, like the old geas.idl files - only generalized" . It would not be different for each provider - "geas would have ONE grpc file - and gfrom that we can generate corba stubs" or equivalent for the RPC protocol in use. He had used .grpc as the file extension, as "I was afraid gr? would be confused/conflict with reports stuff" but "none of this is set in stone" . Derek clarified that "im not opposed to greater than 3 car extensions" - Daniel Baumann (chillywilly) noted "this is not DOS ;)" .
Jan noted that "many protocolls (like xmlrpc f.e.) won't even need an .grpc file, but its good to have one to control access on the server side" . It might also be possible to "Add an lokal socket implementation, which allows any kind of RPC methods, and which writes a communication protocoll into a GRPC file. with this tool it is possible to change your application, or write a new application, then use the special protokoll one time and voila get a GRPC file for normal protocolls" .
Derek said "my concern was if we were to have lots of these - it woudl be worth renaming" . Jason said "well, honestly, I foresee GNUe having a total of maybe 3 of these files - one for geas, one for integrator, one for report server" . Derek agreed. Jason added "well depending on how we do other stuff (Authenticaion Server, Workflow Server, etc) I suppose there could be more than 3 - but you get the point i.e., these are NOT a replacement for GCD" .
�
�
�
�
�
�
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. |