Sacha Schlegel (Sachas) asked Chan Min Wai (dcmwai) whether he had looked at standards (to define certain datatypes like date or address) when he was designing Arias. Chan said he wasn't the founder of aria. Aria was develop by Noguska, a guy name Rayan Fox, as discussed in . He continued Josh was working with the company, and the company just ask him to maintain it when fox leave. At that time I was evaluating Aria for my company use and I find it farily simple so I use it and submit bug doing all kind of customization... and a New release is there. Nothing is fix, Nothing is new and I'm frastrustred. So I shoot them on aria ;) then Josh reply to me and help solve some of the major problem and Josh tell me that Noguska is going to drop this project... so we setup a new things then suddendly, Josh was fire (not due to this but unreasonable) and then we continuate the development... until NOW :). Aria was 6 months old as of time of writing and the website was www.aria-erp.org, demo is on http://www.aria-erp.org/demo/ with username "admin" and password "password". Aria was based on Nola (www.nola-pro.com), however... Nola is not a good / final product.

Sacha Schlegel (SachaS) asked whats the strategy of gnue-sb and aria? Keep to develop both in parallel? Chan Min Wai (dcmwai) explained that when gnue-sb have a web base support aria will be drop. Sacha was interested whether php would be used mainly for web and Chan said: that is still yet to be discuss, but for what I know, it will be using application server + XML to provided that. So that everything can be put direct to the web.

Chan Min Wai (dcmwai) asked how to handle situations where you purchased items in one quantity (e.g. packs) and sold them in another (e.g. items). Mike Vincent (Vee2d2) suggested recording both a Unit of Purchase to go on purchase orders and a Unit of Issue to go on shipping documents and so on. In the stores inventory itself, break everything down == buy a lot of 100 widgets for $100.. they go in as 100 widgets @ $1ea When re-ordering, you would want to order in multiples of the Unit of Purchase - I think currently there's a "ReOrder Qty" field in the item mgmt for the purpose.. When the goods were received, the system should convert from Unit of Purchase to Units of Stock-Keeping.

Later, Derek Neighbors said he could not remember whether re-order quantity was either a. default amount to reorder (i am 99.9% positive this is what i meant) - b. quantity level at which its time to reorder (how ever i think that is reorder level or minqty ).

Jason Cater (jcater) said he had found his old java-based forms-equivalent program that had been abandoned when he had joined GNUe. Ha said his java developing experience had been a bad experience professionally - I had a complete GNUe Forms equivalent package done in Java swing but it was SOOOO slow it was painful. Though, ironically, I ran it today and it runs fairly well on my Athlon MP 2200+. However, programming python was much easier than java or php, which were really more for quick-and-dirty web pages.

Jason Cater (jcater) announced a new release of the GNUe Tools - Forms 0.5.1, Reports 0.1.2, Designer 0.5.1, Navigator 0.0.5 and Common 0.5.1. All of these releases are targeted at developers. The five products are available in source form from our website at http://www.gnuenterprise.org/downloads/current.php. Soon, we will update our all-in-one Windows installer for the GNUe tools that include all the basic dependencies -- you only have to download a single setup.exe! The Installers include support for PostgreSQL, MySQL, and ODBC. Also, Debian packages for "unstable" will also be created. We are looking for packagers for other platforms.

The tools have been tested and are known to run on most common GNU/Linux distributions, Microsoft Windows 95 and higher, MacOS X, Solaris 8/9 and FreeBSD 4.x/5.x. The tools require Python 2.0 or better to run (Python 2.2+ recommended.) GNUe Designer requires wxPython 2.4 or better to run.

He gave the change logs for each product, noting that Designer 0.5.1 in particular was a Major Enhancements Release.

Reinhard Müller (reinhard) said i'm making _way_ progress in appserver, but was now having problems trying to call the Application Server via a Remote Procedure Call (RPC). Calling the Application Server locally using the test.py program worked, but the testRPC.py program gave an "Unknown Error" error message. Jan Ischebeck (siesel) tested this for himself and got a slightly more helpful message - returns a Protokoll error. He confirmed he was using the pw_xmlrpc package for RPC access - its miles better, and included in python2.2[2.3?], so it should be our standart. Reinhard pointed out that it's not available for the current stable distribution (woody) of Debian GNU/Linux - that's the reason why we made xmlrpc standard. However, Jan pointed out that woody was also lacking most modern software, like gtk2 etc., and, as Reinhard noted, GNUe as well. Reinhard suggested that if the sarge distribution became the Debian stable distribution some time this year as planned, then we could switch to pw-xmlrpc.

Later, Jan committed a proper fix for the problem to AppServer, having previously applied a temporary fix in Common. Reinhard suggested i think you could undo the temporary fix in common, couldn't you? Jan said he would prefer to leave it, in case of a user written appserver method is returning None. Reinhard thought that user written methods will be called through a wrapper anyway. Jan noted that his fix only worked with pw_xmlrpc - using AppServer with the xmlrpc package in Debian woody would still have the bug.

Reinhard asked what the "type" flag in the format of grpc files (GNUe Remote Procedure Call definitions) was for - even if you got the type wrong, it still seemed to work. Jan said that type checking isn't implemented in XMLRPC rpc driver yet but its necessary for some other protocolls. Reinhard asked if it was forseeable what the valid types will be? - i could guess that "list of objids" will probably be no valid type :)