GNUe Traffic #60 For 21 Dec 2002 Editor: Peter Sullivan By Arturas Kriukovas and Peter Sullivan text Table Of Contents * Standard Format * Text Format * XML Source * Introduction * Threads Covered 1. 12 Dec 2002 - 16 Dec 2002 (3 posts) 0.4.3 releases of GNUe Tools 2. 11 Dec 2002 0.4.3 release for Forms and Common 3. 11 Dec 2002 Non-free equivalents to GNUe Reports 4. 12 Dec 2002 Debian packages for 0.4.3 5. 12 Dec 2002 Raw SQL in GNUe Reports 6. 13 Dec 2002 HTML User Interface for Forms 7. 14 Dec 2002 Feature Plans on Website 8. 15 Dec 2002 Javascript Forms Client - not needed? 9. 16 Dec 2002 RentFree and GNUe Small Business Introduction This Cousin covers the three main mailing lists for the GNU Enterprise (http:// www.gnuenterprise.org) project, plus the #gnuenterprise IRC channel. Kernel Cousins GNUe is now group-authored: if you'd like to join the team, let us know (mailto:psu@burdonvale.co.uk) . 1. 0.4.3 releases of GNUe Tools 12 Dec 2002 - 16 Dec 2002 (3 posts) Archive Link: "[Gnue-announce] Pre-releases for 0.4.3 available for testing" Summary By Peter Sullivan Topics: Forms, Common People: Peter Sullivan, Jason Cater Peter Sullivan announced "We will shortly be doing an interim (0.4.3) release of GNUe Forms and GNUe Common. This is a bug-fix release on the stable (0.4.x) branch, before the big push for the 0.5.0 releases. As usual, we have pre-releases available for testing on the website" . Later, Jason Cater announced the release - the main changes from 0.4.2 were "Reintroduced runform () to form's trigger namespace" and some fixes to the MySQL and PostgreSQL drivers, as well as "Improved support for the schema scripter" , and other misc. bug fixes. Some days later, Peter also announced "The 0.4.3 release of Forms, Designer and Common and the 0.1.0 release of Reports are now available as a single setup.exe for Microsoft Windows, including many of the supported database drivers." 2. 0.4.3 release for Forms and Common 11 Dec 2002 Archive Link: "[IRC] 12 Dec 2002" Summary By Peter Sullivan People: Jason Cater, Jeff Bailey Jason Cater (jcater) asked "any one tried out the 0.4.3 stuff? or have any objections to doing an actual release tonight? 0.5.0 is practically ready too - but would like to see it get some heavy pounding in the next week or two" . Jeff Bailey (jbailey) said he could do Debian packages for the new releases - "Does the release have man pages?" Jason said "they should - of course, that's why I post prereleases - so others will help me verify everything is included >:)" Jeff said he had previously done packages from CVS "generating my own tarballs with sdist, and that doesn't make man pages, so just checking. Someone - /me glares at derek - filed a bug because the Debian packages didn't have man pages." Jason said the setup-cvs.py script would automatically create man pages. Later, Jason said "we are officially released - source on website - announcement has gone out - and most importantly.... topic has been changed" for the #gnuenterprise IRC channel. "Now that 0.4.3 is out the door and 0.5.0 has stabilized - I'd like to see people start pounding against CVS head" to test it. 3. Non-free equivalents to GNUe Reports 11 Dec 2002 Archive Link: "[IRC] 12 Dec 2002" Summary By Arturas Kriukovas Topics: Reports People: Jeff Bailey, Jason Cater Jeff Bailey (jbailey) asked whether anyone was familiar with reports - "It occurs to me that for one of my projects it would be interesting to have an on-the-fly web-based create-a-report type of system. I'm wondering how much work it would be to adapt reports to that type of thing." Jason Cater (jcater) thought this was not hard at all: "your create-a-report builds the actual report xml, and runs reports, and takes the resulting html and displays it" . Jeff noted it was almost like a "reports designer" with an html ui. He was interested whether the goal was basically to replace something like Crystal reports? Jason confirmed that and said, that GNUe Forms goal is "much more than that :)" 4. Debian packages for 0.4.3 12 Dec 2002 Archive Link: "[IRC] 13 Dec 2002" Summary By Peter Sullivan Topics: Small Business People: Jeff Bailey, Jason Cater, Derek Neighbors Jeff Bailey (jbailey) said "I'm about to do the final packaging for the 0.4 branch for Debian based on the 0.4.3 packages" unless there were any objections. He asked "Why is designer still 0.4.2? No changes?" Jason Cater (jcater) said "the 0.4.3 stuff was for specific bug fixes - not a general release cycle" . Derek Neighbors (revDeke) said "at some point we will need to decide if we want to 'always' synch release of like items or not - i.e. release a designer 0.4.3 even if it has no changes from 0.4.2 except a version number - /me doesnt care one way or another - just its a matter if we tell people forms/ designer/common should all be same version number or not" Jason said "in the past we've tried to say any 0.1.x was compat w/any other 0.1.x api wise - /me thinks the 0.x part should try to stay in synch - but that's just mho" . Derek asked Jeff "you willing to package gnue-sb too? ;)" Jeff replied "Probably, but after glibc is feeling a bit better." Derek had "been meaning to look at deb packaging and try to get gist of it - and try to get maintainer status" . Jeff said "Debian packaging is really simple - The hard part is complying with all the policies." Jason agreed - he "did packaging for our tools in an afternoon" but "wouldn't venture a guess as to how many policies I broke ;)" Jeff said it "Wasn't too bad, but it was a couple of hours to get the important ones, I think." Jason warned Jeff against letting Derek work "w/deb packaging - he already reports enough bugs w/the end-user packages - you really want him reporting bug after bug for debhelper and friends?" 5. Raw SQL in GNUe Reports 12 Dec 2002 Archive Link: "[IRC] 13 Dec 2002" Summary By Arturas Kriukovas Topics: Reports People: Bajusz Tam?s, Derek Neighbors It was asked whether it was possible to put a raw sql query as a datasource for reports. Bajusz Tam?s (btami) said no - he suggested "use them as views in the db" . Derek Neighbors (revDeke) said "im pretty certain at 'one time' raw queriers were supported in both forms and reports" . Derek suggested translating queries into views and then using report parameters to filter - that way it should be much easier. He typed in some sample code. 6. HTML User Interface for Forms 13 Dec 2002 Archive Link: "[IRC] 14 Dec 2002" Summary By Peter Sullivan Topics: Forms People: James Thompson, Jeff Bailey, James Thomspon, Jan Ischebeck James Thompson (jamest) asked Jeff Bailey (jbailey) "how goes the html" user interface being written for GNUe Forms. Jeff replied "I wanted to chat with you to see how important perfect representation is. I can't seem to get a perfect grid. I think the problem is that all of the functions assume variable width fonts, so there's no reasonable way to get the information I need to do it" , pointing to a sample page. James asked "right now you're doing direct placement right along the lines of pseudocode like - print label 1 at x*whatTheBrowserThinksIsASingleCharWidth and y*yadaYadaCharHeight - is that correct? so how hard would it to seperate this renderer (i guess I'll call it that) from the logic dealing w/ passing data back and form state - then the renderer would basically build the html and a single call like render.publish() would spit out the html - you could then use a different html table based renderer in place of this for the time being" . He was not sure how the existing phpForms client did it. Jeff said "If I understand the current renderers they get a series of calls to add widgets and then display their form, usually deferring that off to the toolkit, and then just invoke the display. We can just buffer that, assuming that I can do some sort of class scope variable, or global variable. The thing is, I don't see how you could do it with tables either. Also with tables you lose any accessibility and PDA rendering you might've had. (You might not have it anyway, given that label and form widgets aren't really associated) I think if I could see a form that's done with tables, I could certainly figure it out with CSS> Tables are just going to do it with pixels, and I can use those just as easy." The problem was "getting a monospace grid. HTML's not tuned for that, since it's pretty rare that someone would want to do position on a monospace grid." James did some digging, and discovered that the code for the simple client (http:// www.gnuenterprise.org/~jan/phpforms/gnue-forms.phpphpForms) had been in Jan Ischebeck's (siesel) home web directory - "it didn't get reactivated after the crash" but he restored it from the back-up. Jeff had a look - he felt it produced very ugly HTML. 7. Feature Plans on Website 14 Dec 2002 Archive Link: "[IRC] 15 Dec 2002" Summary By Peter Sullivan People: Jeff Bailey, Peter Sullivan, Jason Cater Peter Sullivan (psu) changed the website to include a visible link to the Feature Plans, as previously discussed in Issue #55, Section #10 (7 Nov 2002: Feature plans for GNUe) . Jeff noted "I think it's funny that the two feature things in the 0.8.x releases are ones that I'm working on. ;)" Peter said "this is the hidden benefit of feature plans to our core developers - which I don;t think jcater/jamest anticipated - People look at the plans, see something is listed for the 9.4.99 release and feel the need to scratch the itch sooner" . Jeff said "I started working on them before I saw the feature plan. =)" It was noted that the hyperlink to the outstanding critical bugs in DCL (GNUe's own bug tracking/ project management tool) was not working. Peter said "should be https://www.gnuenterprise.org/dclgw/ (https://www.gnuenterprise.org/dclgw/) " . Jason said "hehe - well, we want to make ppl work to file bugs - we don't want it to be easy, after all" . Peter thought "that a bug in the link to report bugs is verging on paradox, or at least infinite recursion" . 8. Javascript Forms Client - not needed? 15 Dec 2002 Archive Link: "[IRC] 16 Dec 2002" Summary By Peter Sullivan Topics: Forms People: Charles Rouzer, Jeff Bailey, Jason Cater, Derek Neighbors, Reinhard M?ller Charles Rouzer (Mr_You) asked "how is jan coming along with the jsclient?" He would use this "for screen writes/updates" as previously discussed in Issue # 52, Section #22 (20 Oct 2002: Javascript forms client) . Jeff Bailey (jbailey) said he had not looked at this, but "I think anything needs to be integrated with gnue-forms." Charles said "using jsforms for screen writes eliminates having to redo it in HTML - also allows screen updates without reloading. jsForms will then have two builtin methods for connectivity: appserver via XMLRPC and webserver via CGI - or you could make them seperate instead in one client. or one code base." Jason Cater (jcater) said "I don't see the two being compatable in the same client - either you use the gnue-forms backend or you don't in a client" . Charles said "your gnue forms backend in this case is the CGI" . Jason said "then you aren't reusing the gnue-forms backend" . Charles understood, but said that the "bottom line is, if you don't use javascript you'll hafta reload the screen for every request.. which is fine, but not very pleasant. so why not just use javascript for webbrowser layout. javascript XMLRPC client is also very light.. should require nothing but appserver.. I don't see much point in writing an HTML based XMLRPC client when it can all be done in javascript." Jason was not sure of the need for "an XMLRPC client in js" . Charles said "then why even bother with an appserver? we should just expect users to connect to our database across the internet?" Jason said "it's not n-tier vs 2-tier AT ALL - it's about diversion of code bases - you in effect are ditching gnue-forms for an appserver + javascript half-ass solution" . Charles said that javascript was the only way for an HTML client "to eliminate reloading of screens/pages" - eliminating "screen reloads makes a webclient FEEL like a real client." Derek Neighbors (revDeke) said "if your requirement for a 'web' application is that it 'feel like a real application' - why not just use a real application - for example forms is fully 'internet' aware" . Charles said "thin clients" was the issue. Derek said "last i looked gnue-forms was smaller than about any webbrowser out there - for those with a preoccupatino for putting the kitchen sink in a webbroswer so they can say 'zero administration' i will gladly make a mozilla plugin of gnue-forms that doesn nothing but install forms - and call it via plugin architecture - just like flash and java do" . Jeff suggested "there should be a single integrated forms back end" - "With a javascript, don't you have to provide all the forms functionality rewritten in javascript?" The HTML User Interface he was working on would just use the normal GNUe Forms code, with a seperate HTML UI wrapper, accessed via CGI. Derek clarified "btw: im not against having javascript of sorts in an html client - i am against rewriting forms client in javascript" Even though not all broswers supported it, he personally felt "that supporting only 'modern' browsers woudl be acceptable" . Charles felt that his approach was not that different - "all you are doing is eliminating your HTML screens with javascript screens.. the javascript code would then communicate with the CGI/gnueforms to update the forms, etc, etc. - look at javascript as a blank canvas that allows you to communicate with the server in the background. and how is that not the same with HTML?" Jason and Derek still felt this involved re-implementing a lot of existing GNUe Forms code from python to javascript. Derek said "look at the UI driver - and UI driver system" . Charles said "I'm saying that instead of writing a bunch of HTML output routines and creating a normal clunky web client, just add some javascript to enable background communicate and eliminate screen writes.. no big deal.. doesn't require rewriting forms client.. just involves using javascript instead of HTML output." Jason said that any HTML client should work in the same way as the other UI drivers, with the UI driver sitting on top of the core Forms code and producing HTML - what Charles was describing was more like re-writing both the UI driver and some of the core Forms code in Javascript. Charles said "CGI (gnueforms) outputs SOMETHING... right now you are wanting to output straight HTML... why not integrate javascript to build forms from the CGI instead of HTML? either way you have to do one or the other.." Jason said "because that ties you to javascript" . No-one else seemed to see this as an issue. Jeff said the important issue was "that there must be no business logic in the jsForms package. appserver needs to hand out "display, to the best of your ability, the following widgets" If it can provide hints on top of that, like "numeric only field" that jsForms can benefit from, great. But that business logic to sort all of that out can't be in the cilent. That's important for a few reasons: 1) We should minimize the amount of trust we have of remote clients. 2) We cannot chain ourselves down with implementing business logic in many places. My opinion is that eventually there's a place for jsForms - in that gnue-forms *also* shouldn't be trusted. I would love to see a version of gnue-forms-server that communicated to all of its clients through appservers. Because right now it's still possible to hack gnue-forms. We're still trusting code running on an untrusted machine." He thought "potentially the HTML client should use Javascript as an add-on. Note that it can't be required if you want to do much with PDAs and cell phones. (I think they are the most interesting market for the HTML client long term)" . Reinhard M?ller (reinhard) had "just seen a cell phone running an SSH client last week" . 9. RentFree and GNUe Small Business 16 Dec 2002 Archive Link: "[IRC] 17 Dec 2002" Summary By Peter Sullivan Topics: Small Business, RentFree People: Jason Cater, Derek Neighbors Jason Cater (jcater) "really wants to tie RentFree" , the GPL property management application he was writing with the GNUe Tools, "into GNUe-SB too - /me is really interested in the gl/ap parts of it - so maybe we can align goals - so I could be working towards one part while you do other - as I know gl/ap wasn't at the top of your needs list" . Derek Neighbors (revDeke) agreed - "thats why i want to fully feature plan gnue-sb - i plan to break it into 'segments' like contact management, inventory, product managemetn, etc etc etc - each with own 'plan'. Hopefully multiple people will be working on it, with different people doing different parts - but all parts aligned - i had started a plan but" did not have it to hand as of time of writing. 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.