GNUe Traffic #63 For 11 Jan 2003 Editor: Peter Sullivan By Arturas Kriukovas and Peter Sullivan "GNUe Common is what gives a GNUe Jedi his power. It's an code base created by an AI. It surrounds us and penatrates us. It binds the GNUe Framework togethter." Table Of Contents * Standard Format * Text Format * XML Source * Introduction * Threads Covered 1. 1 Jan 2003 Project PAPO and GNUe 2. 3 Jan 2003 SKUs in GNUe Small Business 3. 3 Jan 2003 Converting forms to new .gfd format 4. 5 Jan 2003 Format Masks in GNUe 5. 5 Jan 2003 Triggers in GNUe Reports 6. 5 Jan 2003 Using Reports to produce customer invoices as PDFs 7. 6 Jan 2003 Bayonne, the GNU telephony project 8. 6 Jan 2003 Application Server API 9. 7 Jan 2003 Getting started with GNUe Forms 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. Project PAPO and GNUe 1 Jan 2003 Archive Link: "[IRC] 02 Jan 2003" Summary By Peter Sullivan People: Marcos Dione, James Thompson, Derek Neighbors, Federico Heinz Referring back to Issue #56, Section #13 (14 Nov 2002: Merging GNUe and Papo CVS code) , Marcos Dione (StyXman) asked "does anybody knows about the inclussion of features implemented in our patch into gnue?" James Thompson (jamest) said "i'm still working on it" . He had been "hoping to get to over the holidays" but was now hoping to start this week. Later, Marcos asked "did you hacked anything in the way of
" , as discussed in Issue #61, Section #8 (22 Dec 2002: Dialog boxes in Forms returning parameters) . James said "a fair bit of the work is done" - "i just need to make some more adjustsment to the UI" . Marcos asked for any hints as to how this would work - "I need to either reproduce it or backport it when is done." James said there would be radical technical changes - "I wouldn't reimplement - if you can give me the time was to be able to replace your genericBox - i planed on that being a dynamically created " . Derek Neighbors (revDeke) said "no offense if you would use official cvs you would save a LOT of time" . James pointed out that papo were still using their own CVS as "I'm still trying to merge their changes up stream so they can migrate up" . Derek said "that was my point - it takes time away from adding new features to try to sync with them - and then they out of sync again" . He "isnt overly concerned from a gnue standpoint, just would like to help papo out by giving a consistent tree" - but the "gnue team cant constantly spend time trying to resync" . Marcos said that, for some time, "we (almost) stopped to add features to our cvs ('cept for bug fixes)" . Marcos added "I guess we'll have our cvs anyways, as we have functionality that will never get into gnue. unless there were other ways to introduce them, like delegation in the db arch" , as discussed in Issue #50, Section #3 ( 2 Oct 2002: Adding delegates support to GNUe Common) . Derek said "so what you are saying is you want a fork" . Marcos disagreed - "it's the last thing we want." Derek said "well if you have your own cvs you have a fork" - "it might be a minor fork but a fork none the less" . He felt that GNUe had "bent over backwards to apply patches that you would stop using your own cvs so we wouldnt have such headaches" . James said "we're not fast enough for their business needs - that's all - i mean it's been weeks/months(?)" Derek said "well its a two edge sword - you have dialogs almost done and styxman will spend two weeks implementing or back port - so whom is slowing whom down" ? Applying patches generated from papo's CVS back into the main GNUe CVS was time-consuming, and was only really worth it if papo were intending to use GNUe's CVS in the future. Federico Heinz (perlhead) said "We most definitely *don't* want to fork. We're doing our best to work with what we currently have." Derek emphasised that he was not opposed to forking - "there are two types of forks - a pure fork... we make foo, you want to go right i want to go left and we fork - and - a mild fork, we make foo, you want to go right, we want to go right, you want to dress in red, we want to dress in blue - in a mild fork it makes sense to 'share' as much as possible - as things are going same direction." He "would rather see papo just use gnue and drop own cvs" but "understands business requirements and timelines" . However, "just like in a data conversion if you continue entering data in old system you will never cut over to the new one" . He felt that "this dialog sample proves as well - there is functionality that might come into our cvs you want - and its murder for you to back port it." However, "if dialogs will take you 2 weeks to do - and its in our system - and if it takes two weeks to get cvs head to give you proper functionality" , then there was no issue as the work could be done in GNUe's CVS directly "and you are in sync - /me isnt saying thats the case - but you have to look at such trade offs" . Federico said that getting the papo CVS in sync with GNUe's would take much longer than two weeks - Marcos had "played catch up for quite a while in nov/dec, and he never got anywhere near the head branch." Derek felt that the only way to re-sync was "to check out our cvs - then add the functionality to it thats missing and submit as patches - one patch per functionality - not a giant patch - a. that will minimize amount of wait time you would incur from us - b. that ensures our cvs does what you need - in the mean time stop adding stuff to your cvs" . Federico said that the "Problem is, as I understand it, that if we do that, our stuff STOPS WORKING. And we must have a widely deployable version in two months. Debugged and tested." Derek said "well then i would say it behooves you to do ASAP - unless you forever want a fork - as if you deploy you will NEVER get back to our cvs - as you will never be able to 'stop' adding features to sync up. Again im not saying you must do this, or even necessarily that you should do this - that is up to you - just be forewarned we wont take patches created from a cvs other than our own" . Marcos did not think there was actually much difference in functionality. Federico agreed - "there's not actually that much more that we need... just now, a few UI things, and then we can rest." Derek warned that the forthcoming changes to the GNUe Forms Definition format (.gfd) in version 0.5.0 would make papo's CVS "incompatiable going forward without MAJOR work on your tree" . Marcos noted that there were some changes in papo's CVS that "won't get into gnue ever. and we know that." Derek said "for somethings like that if one off deals you could treat like" patches to the Linux kernel, "where its a 'mini fork' for specific functionality" . Federico agreed, but said that the bigger issue was "We have stuff we need, and that GNUe wants but does not yet have in HEAD." Marcos said that, as papo had several devlopers, they would still want to have a CVS even if just for version control on their own patches. Federico fully appreciated Derek's point about ideally merging CVS before papo did a wider release, but "it's a financing thing" - "if we get a solution that *works* by march, we get the funding we need to continue work, and that work goes according to *our* schedule." Derek could relate to that, but warned "if you dont make papo tree like 0.5.0 it will be an utter bitch for you to back port any new functionality we put in" . He appreciated that papo "have always been more than eager to share their improvements, i want to make it abundantly clear the gripe is not that they want to fork gnue and not give back - its more that applying patches is utter hell, because they are created off a cvs tree other than our own and in masse" . Federico said that the funding situation "means that we *will* do some shit twice, which we could have gotten right the first time. But if doing so will cost us our release date, we won't even get to the point where we can get it right once." Derek agreed - "the question is does it outweigh what it will cost you to merge the other stuff over" later? Once all of the papo patches from November had been applied, "our cvs head after those patches might not be all that radiacally different feature wise - anywho its up to you guys to decide whats best for you" . Federico said that papo's clients were not that used to software development cycles - they were "Sustainable development organizations, mostly." - "They have great trust in us, and we do all in our power to keep that trust." 2. SKUs in GNUe Small Business 3 Jan 2003 Archive Link: "[IRC] 04 Jan 2003" Summary By Peter Sullivan Topics: Small Business People: Mike Vincent, Derek Neighbors Further to Issue #59, Section #14 (8 Dec 2002: GNUe Small Business and demo application for GNUe) , Mike Vincent (Vee2d2) said he had "been thinking about the SKU thing.. I can imagine 3 ways to organize a" Stock Keeping Unit (SKU) - "1) Simple serialized number which is N digits long. 2) A number with N segments one or more of which are a serialized number and one or more are derived from predefined lookup tables and 3) a segmented number completely derived from lookup tables" . Segments could either have "a predefined padded length" or be "delimited with or without a contraint on their length/scope." If "there was a way to configure how a SKU were established, then you could use that information to create your forms to manipulate them based on that configuration." This meta-data could be queried to build the "form according to the data extrapolated. Descriptions would be labels, if the segment was a lookup a dropdown could be created, etc.." Derek Neighbors (derek) said the "way i planned on doing it was drop downs and triggers - you selected the 'categories' or such that generate the numbers" . He added "i really think making a dynamic form is a bad solution - at least in the gnue world. Maybe for gnue proper - but getting sku numbers that complex in gnue-sb i think is over kill." The main requirement for his clients was to be able to generate new SKU for new items using pre-existing categories from drop-down lists, but also use SKUs that did not fit the standard pattern - "i.e. the sku# is a free form field - but you can use the categories to generate a number" . His users would typically have three levels of category. Mike said that, with too many segments, this could "would create very large numbers and very large numbers are hard to manage outside of the computer." However, as "if I were a consultant this could be a bonus to be able to adapt to a running system rather than expect a migration if things didnt fit." His "numbers are completely derived from lookup tables and are in 5 segments/ categories" . 3. Converting forms to new .gfd format 3 Jan 2003 Archive Link: "[IRC] 04 Jan 2003" Summary By Peter Sullivan People: Marcos Dione, Dmitry Sorokin, Jason Cater, ra3vat Marcos Dione (StyXman) asked "how should I use the .04to0.5 conversor?" Dmitry Sorokin (ra3vat) said "run it with your form as param - old form will be saved with -PRE050 name" . The conversion routine, which was designed to convert GNUe Form Definitions (.gfd) from the format used in version 0.4.x and earlier to the new format that split the logic and the display, was not completely automatic, but "in most cases mine worked" . Marcos said "ok, I'll finish the file by hand" . Later, Jason Cater explained that the syntax for the conversion script was "gfd04to05.py [] - if you specify two names on the command line, then the second one is the output name and the first one is left unchanged - if you only specify one form, then the original is renamed and the new one is created in its place" . Earlier, Marcos reported various errors trying to run a converted form, most of which seemed to be caused by the convertor putting "all my buttons in the logic part" . This was a very simple form, just with a few buttons. He wondered if this was the problem - "can a form have no logic?" Jason asked "do you have a