GNUe Traffic #77 For 19�Apr�2003

Editor: Peter Sullivan

By Peter Sullivan

"/me was just showering" - "/me too - we're breaking the stereotypes - no smelly geeks around here - no siree!"

Table Of Contents

• Standard Format
• Text Format
• XML Source
• Introduction
• Threads Covered

  1.	10�Apr�2003		Pricing mechanisms in GNUe Small Business
  2.	11�Apr�2003		GNUe architecture
  3.	12�Apr�2003		Integrator and Reports
  4.	14�Apr�2003		Application Server and Class Definitions

Introduction

1. Pricing mechanisms in GNUe Small Business

10�Apr�2003�Archive Link: "[IRC] 10 Apr 2003"

Summary By Peter Sullivan

Topics: Small Business

People: Nicholas Lee,�Mike Vincent,�Derek Neighbors

Nicholas Lee (esands), referring back to Issue�#72, Section�#3� (10�Mar�2003:�Pricing mechanisms in GNUe Small Business) , said "We have multiple pricing levels per item, a seperate discount table per customer, main cost price and an alternative supplier cost price table per item. Ability to set parent/child relations between customers and master parent price lists. I'd consider that all basic functionality for a decent system" . He felt that "some nice features would be 'scheduled' price levels" for temporary discounts - "Also a similar mechanism would be useful to scheduling permenant price changes" . Mike Vincent (Vee2d2) suggested "So if we added say a start date / end date fields to the tiered pricing table eg: id, sku, qty, from_date, until_date, price then that would satisfy your needs?" Nicholas noted that "Pricing is one of the most complex parts of business. 8) Anything that can be done to improve management would be well received" . Mike pointed out, however, "that we're trying to keep things simple at this stage" - "I think the focus is to have something from which we can later come back and build on" . Nicholas felt it was important even at this stage to "think about normalising the pricing schema away from the stock information and stock levels. However, dealing with discounts based on i) qty breaks, ii) time periods, iii) specific customers, iv) payment basis (ie. cash discounts), v) operator selected. All different things that require some addition information." Derek Neighbors (derek) confirmed "i dont discount your opinion on discounts - but part of me says it will be pretty darn simple to start and grow from there" .

2. GNUe architecture

11�Apr�2003�Archive Link: "[IRC] 11 Apr 2003"

Summary By Peter Sullivan

Topics: Common

People: James Thompson,�Jan Ischebeck

James Thompson (jamest) said "gnue is a few different things - and all of our tools are designed to work independent of the others - so you can what you want. If you want a simple client/server setup say a graphical front end to a database you can grab forms and write the xml files by hand. If you want a middle tier w/ business objects you grab appserver and define your objects in there. Forms has a appserver interface so it'll not really know the difference - it's still just a datasource. Appserver/forms communicate over gnue common's rpc abstraction library - but I know little about it" . Jan Ischebeck (siesel) had shown James "a demo the other day - with appserver tied to a javascript based forms like setup running over the web - it was pretty slick" .

He emphasised "really you can just grab the pieces you want - the only thing all current tools depend upon is GNUe Common" . "the common docs are not complete - and the ones I'm working on are targeted more toward using common outside of gnue - but it's the same as how we use it :)"

3. Integrator and Reports

12�Apr�2003�Archive Link: "[IRC] 12 Apr 2003"

Summary By Peter Sullivan

Topics: Integrator, Reports

People: Jan Ischebeck,�Derek Neighbors,�James Thompson,�Jason Cater

Jan Ischebeck (siesel),referring back to Issue�#58, Section�#6� (29�Nov�2002:�Scope of GNUe Integrator) , asked if Derek Neighbors (derek) had ever written up his "proposal for integrator" - if not, Jan could "try to write a proposal and post it to gnue-dev to get comments/changes etc." Derek said he would still like to do the first draft - he felt that he and Jan had different ideas about Integrator, with Jan seeing it as just an extension of Application Server. Derek's view was that it was more closely releated to Reports and Common, much of which would be reused. In the meantime, "the two biggest things you could do to help integrator is develop a rock solid ascii driver and a rock solid xml driver for common/dbdrivers - as those will be the two biggest data types folks will use" with Integrator "(in my experience)" . James Thompson (jamest) noted that he and Jason Cater (jcater) had "talked about reports/integrator a little - at one time we talked about the possibility of changing the way reports handles some things so that it would almost be integrator" - especially since "reports has a plugin output system" . Derek said that Reports was already capable of doing the output side of Integrator - "the big problem is the 'import' side is not there - so i can have a datasourceX - and use reports to pump it out to xml formated however i want - but i dont have a way 'in reports' to import that data back in. I think the two things 'integrator' needs to do is provide that import mechanism and provide a ui to do 'mappings' - whether that needs to be a separate tool from reports i am not sure" .

4. Application Server and Class Definitions

14�Apr�2003�Archive Link: "[IRC] 14 Apr 2003"

Summary By Peter Sullivan

Topics: Application Server

People: Henry Mason,�Reinhard M�ller,�D. Smith

Henry Mason (deprogram) asked "there is no way to populate a DB backend directly from class definitions, right?" Reinhard M�ller (reinhard) said "not yet - we certainly want to have such a possibility" as "the new appserver stores its definitions in the database - and we want a way to create the db schema out of the definition" . henry asked "there has to be some database agnostic way to create the definitions? that get stored in the database?" Reinhard said "there has been much talk about how to "author" the definitions - one way is to have a form that accesses the tables of the database that contains the definitions - like a form for item management you have a form for class management" .

D. Smith (dsmith) said this was "always a problem with dbs. How do you bootstrap them. The best place to store stuff is in the db, but how to you get to the db to find out "how do you get to the db" ?" Reinhard said "appserver will have a way of "bootstrapping" the very basic table definitions for the tables that hold the classes and properties and so on - those basic definitions will be written in a .ini file. That .ini file will be read by appserver and appserver will "bootstrap" the database - and when we have these tables then we can fill them with "user" tables like item, vendor, customer..."

Henry asked where the GNUe Class Definition (.gcd) files fitted in. Reinhard said these related to the old version of AppServer, called GEAS (GNU Enterprise Application Server). For the new version, the intention was to support multiple formats, including .gcd but also XML, ODL (Object Database Language) or whatever people wanted to write a driver for. He explained "we started to dislike .gcd as we learned that most businessmen won't be able to understand that syntax - the syntax of .gcd is quite understandable if you have some years of experience in C or a comparable language - but not for a businessman. However adding a new property to a class with a visual form will be easy even for Joe Accountant :) - especially if the prpoerty maintenance form looks similar to the customer maintenance" . Henry agreed, but said "user friendliness has its drawbacks - my current project involves replacing a system that was TOO friendly - any user could make arbitrary changes to database schema - the result was a terrific mess :>" Reinhard felt this was more "a matter of access control then" - however, he was "not quite a friend of programs that include an IQ test before letting you do something ;-)"

Reinhard said that, as of time of writing, the "primary focus is getting appserver to a useful state - creating a few forms for class and property management is a piece of cake with designer i guess - and then we would have to make this app that creates the db tables from the class definitions" . With GNUe's architecture, "the abstraction of db schema maintenance for different dbs must be in common" as "common has functions to create and update db schema" but Application Server would need code to parse the class definitions and tell "common what to create/update" in the first place.

�

�

�

�

�

�

Sharon And Joy
�