Todd Boyle asked Would your projects be willing to provide documentation of your transaction ledger or journal data schema, and if available, your GL interface, to this collection, at http://www.arapxml.net/research.htm? Peter Sullivan said that, as GNUe and all its documentation was under the GNU Public License (GPL), you don't even need to ask. . He noted It looks as if the main focus of your site is trying to get some kind of standard XML definitions for General Ledger data, and noted that GNUe used XML extensively, for forms definitions, report output and data integration, but not for data storage.

Jens Müller noted that a new law in Germany requires that the user agrees in processing and storing of his personal data. But not only that - this agreement has to be electronically documented. This would impact on areas of GNUe like CRM. Todd Boyle thought that privacy laws existed primarily for the benefit of governments and Corporations which they invented and said Give us secure platforms, and authentication. That's all we need.

Jon Guiton added This is also true in the UK under the Data Protection Act. Neil Tiffin said I see this a easily accomplishable. If someone would write a concise description of the requirement we will add it into our requirements. We expect to have several specific country adaptions and have allowed for these in the design (we have not started the implementations yet). Jens Müller outlined the requirements, and Neil added this to the documents.

Stan Klein said Take a look at the draft security proposal I developed. It is posted on Neil Tiffin's page. One issue I began to try to address is the information security infrastructure required for meeting European Community (EC) privacy requirements. (BTW, the privacy requirements in Europe have been much more stringent than those in the USA for many years. I remember reading articles about the issue in the early-to-mid 1970's.). He felt The best GNUE can do in the area of information security and access control is to enable a user to apply the functionality that the operating system and other infrastructure elements provide. To that end, my draft proposal tries to begin identifying how to do that and to simplify the user's task in applying the functionality. He thought The tricky part for GNUE will likely come from any mandated test and compliance demonstration/certification requirements included in the legislation..

Earlier, on IRC, Peter Sullivan (psu) said I don't think it's a major issue, basically just good data protection. The UK has already implemented the directive - and the sky hasn't yet fallen. Of course, US data protection laws are much weaker - hence the need for "safe harbour" provisions for companies wanting to share data from EU to US arms Derek Neighbors (dneighbo) commented looks as though you are saying Europe is going gungho privacy - while US is going gungho let corporate intellectuall 'property' override everything - with addition of 'terrorist' legislation. /me fears soon we will see following: in Europe its against the law for software to easily get at customer data or transmit - and - in US its MANDATORY for software to easily get at customer data and transmist it :).

Jijo Sevilla (TypeRite) said he was interested in GNUe as it's written in Python. :). James Thompson (jamest) said actually we're writing in python but will drop back to C where he hit performance problems - or in the case of geas....it's all in C at this time. Jijo thought that sounds like a very good way to do things. Python as the glue, with C handling the performance-intensive portions. . He said he was just lurking for awhile, if you don't mind. Going through online documents seeing how things are and if I can do anything to help. GNUe is the only open source ERP solution I know of now, and the fact it's written in Python makes me jump up and down in joy. :).

J Beyer (jbeyer) asked how much of the gnue code is actually working? or lets put it this way: is anybody using it in production? James said as for forms and designer they are usable today - they are also used in production. He confirmed GNUe used XML for forms definitions - they were using pyxml - with our own custom wrapper parser.

Jijo asked which was the best module to start with if I want to get a feel of the code? James said that On the python side of the fence, gnue-common is the core of forms, designer, navigator, and reports. It provides a lot of the core functionality of these tools - a dictionary based xml parser that maps to GObj (our base python object) trees, a data engine that has drivers for every python db api 2.0 available (we'll also support non-db api 2.0 drivers), a app framework that embeds a debug system, config system, profiling system, and so on. He explained forms is our user interface system - designer currenly writes only form xml files - however its capable of handling any xml format defined in our GParser format. Reinhard Müller (reinhard) said that geas is in a state where it basically works (more or less) but the code has become unmaintainable and we are in the process of rewriting part by part - so if you are a "developer" we would greatly appreciate help in doing this as it's hard and time consuming work - if you are a "user" you'd better keep your hands off geas for the time being :) James continued Navigator is currently a brain dead navigation system - its a quick hack based upon common that lets you define processes - these processes define steps that run forms, or apps - some day this will support role based access control but not today :) Reports can generate reports :) - but is not complete - it can be used however - it's author used it to generate something like a 10,000 letter mailing to their customer base IIRC.

He suggested so to play - i'd grab common, forms, designer if python was your thing, i'd grab geas if C and object servers are your thing.

Derek Neighbors (dneighbo) welcomed Arturas Kriukovas (Arturas). Arturas said he was fluent in Delphi. Derek said that, as an ex-Delphi programmer himself, python is a VERY easy transition from delphi. Arturas said he was keen to help anywhere and everywhere! Derek said possible areas to start were:

He suggested i think we should talk to jcater and jamest and see if they have some stuff in forms or designer that we can start you with that will allow you get a better understanding of the internals of gnue, but while doing something useful :) He was looking for our current TODO but i can not find it so we can discuss tomorrow. He wished Arturas Labanaktis ('Goodnight' in Lithuanian).

The next day, Derek suggested specifically we think you could help a lot with internationalization . James Thompson (jamest) said they had a a patch that allows for unicode in forms that needed testing and applying. He said Arturas could take the existing tools - and make with work w/ unicode and/or localization features - so that you could write a form in russian - have the menus and such appear in russian - store russian in the backend. It's as much a design job as a coding job as we can do some of this now - it's just doing it correctly that needs attention :).

A few days later, Derek asked jcater / jamest can one of you update the TODO (and roadmap) for forms, common, designer? - this way when arturas stops by i can give him something definitive to work on .

On IRC, Jan Ischebeck (Jan) asked How difficult is it to write an other "connection" to GEAS such as SOAP or RPC. Reinhard Müller (reinhard) said this would be easy once GNUe Application Server (GEAS) had been re-written to use GNU-RPC, as this would abstract the transport layer. As at time of writing, however, this would be very difficult because CORBA code is spread all over geas. He was actually rewriting geas part by part, starting with the parser, then moving on to the database abstraction, which would use GNUe Common, and the method calling part. Jan asked about the mechanics of the re-write. Reinhard said you are exactly pointing out the main problem i am facing - i change the main code which is a major PITA and breaks other parts of the code. However, it forces me to look at the "main" code and understand how it works - which will (hopefully) help me when replacing the next parts. Jan said there were other possible approaches, but didn't seem to think they were much better.

Neil Tiffin (neilt) suggested i say we just re-write it - I think a complete rewrite would allow to separate out parts better and get more help - also I think we should be thinking about multiptle servers instead of one monolithic one - we need to build it from the ground up mult-threaded - with a workflow engine at the core :). Jan suggested why don`t make the object templates a kind of active, so you just need a container to build them up and store them, and let there buisness logic kind of work. so different templates can be connected with differnt servers or diff. threads... .

Derek Neighbors (dneighbo) said it was important to not add rpc stuff to geas, as this now belonged in GNU-RPC/GNUe Common - if you want to be productive in moving it forward look at common and there are some rpc abstraction classes there. Jan noted that GNUe Common was written in python, whilst GEAS was in C. Derek said he would prefer the new GEAS to be written in python for coherency and speed of development - and if parts are slow its easy enough to move them to C. Jan asked about concrete plans. Derek was concerned that there seems to be a rising division of ideals - so at some point we either converge or diverge. However, not all the right people are hear right now to have this dicussion (thus is the problem with time zones) :). Neil felt that geas is a great subject to talk about - its just not the main focus of the project. Derek disagreed - it was just that Forms had developed faster than GEAS. Neil said that Forms wasn't working with GEAS. Derek said this was because of iirc its a bug in orbit-python. Neil said he hadn't had any problems, and on GEAS the only real outstanding issue is that the search IDL is nto so good. Derek said we really need to talk more about it, and suggested a get-together for all interested parties next week.

Two days later, Derek said he thought there was agreement that workflow didn't belong in GEAS, but we need to be aware of it and talk about it during talks of geas . Neil agreed - I dont want to design the workflow server right now - I want to allow for it and have a general understanding of where it fits, and pointed to his diagram at http://www.gnuenterprise.org/modules.php?op=modload&name=NS-My_eGallery&file=index&do=showpic&pid=31 . Derek said it doesnt look horribly wrong but will have to chew on it about. Neil said it was only a basis for discussion - I would like to get a similar drawing for common - so we can discuss how to use bits of common and merge it with geas.

The next day, Reinhard referred to the problems he was having keeping the old and new parser code in sync, and commented the more i think about it the more i am for a rewrite from scratch - especially if i look at the pain i went through with this double parser phase.

Neil asked did you see the new diagram for geas and do you have any comments?. Reinhard said he thought the SQL generator should be integrated in the database adapter - because the sql is database dependent. He was more worried about when to create the tables and columns in the db - and what to do with dynamic changes to the object definitions.. He outlined a possible way of doing this, where the extra field would be created and stored just within GEAS initially, but when access to a column is requested, and the column doesn't exist in the in-memory table it first rescans the schema of the table (in case someone else has created the column meanwhile) and if it still doesn't exist the column is created "on the fly". Neil was worried that the data base could be filled with a lot of garbage, even with Reinhard's suggested clean-up procedure. He felt there should be some manual process, rather than unrestricted on the fly adding of columns. Reinhard suggested this could be not completely "invisible" for the user but triggered by a call to some procedure in geas.

Later, Jan asked whats about the old buissness objects, after a change of an table?. Both Reinhard and Neil thought, as Neil put it, only adding allowed in auto fashion. Reinhard noted that also we would have to restrict that a new column may not be NOT NULL.

In any case, the "batch" method must exist in parallel to bootstrap a system. Neil said that the batch system and the SQL generator could share a lot of code. Reinhard went further, i see batch system being an automatisation of sql generator. This would mean that the "object server" translates outside access on objects into calls of methods and access to the database - while enforcing things like security and integrity. Neil agreed, but said this would mean we need to break the business object = table restriction. Reinhard said that had already been discussed, and said while travelling yesterday i made some notes on my thoughts on geas on paper - i will write down and combine with your last mail somehow to get a "whitepaper".

Neil asked how much his GEAS diagram mmirrors common :). James found several points of comparison. He asked is old geas no longer considered worth maintaining? IOW...is this a new geas?. Neil said the problem with the existing GEAS was that no one will support it with forms - so we are stuck in limbo. James said he had tried on linux and solaris w/ same resutls - a segfault every time I use a boolean. He continued that he would like to see a merge in the code bases between GEAS and GNUe Common, and a fleshing out of the object model in forms - it's there as a stub. Neil said that the only thing a user interface such as Forms should need to know was the name of the object and whether it returned a single or mutliple results - geas should not export objects - it should provide an interface to the UI. James said right now geas doesn't give me anything postgresql doesn't - it's a relational view of object data. Neil said this was why business object should not equal database table. He added we should be able to normalized data on the backend without effecting the UI and that should be hidden behind the business object - also the business object should provide security. Also, you should be able to say in the UI "GIve me the object pointed to by this field" - the object servers should serve it up. James agreed, but this is way ahead of where we are today :). Neil said that is why we need some new architecture.

Derek cautioned against getting into detailed discussions ahead of the set meeting - as half conversations between one or two people just make it more laborious to unify us and make sure all the key players were included. It was agreed to keep things informal for the moment.

Derek suggested honestly i would like next geas to start out with no objects - just an abstracted rpc that talks to a daemon that gives data access and remote method innovaction - as that should be very simple with a large gain - learn from it - come back and do a real geas. Neil felt this would be a retrograde step - then we drop back 2 years and dont get any benefit from what we ahve learned - we also extend the time to get a working enterprise system - if you want a db system, just use current forms and GNU-RPC. He felt the real issues to making a middleware werver work is the object handling and its relation to SQL. Derek said the big difference here is whether we make our middleware object transparent or whether we push that back to the developer. Most systems made object/SQL mapping the responsibility to the developer, wherease GNUe could offer an object transparent system - just its VERY VERY difficult compared to the former - and why i was suggesting a more evolutionary approach. Neil felt we are almost there now - sure we have some problems but so does forms. Derek felt we have a much better idea of what is involved but i wouldnt say almost there :) - much closer than most though :).

He noted the people doing most of the coding right now are not showing extreme interest in object transparency (though they are not saying they wont support doing it in gnue). He would rather have a limited but working GEAS which didn't offer object transparancy, rather than sit with an unused half done thing for a long time, which only makes gnue look bad - if we can get a ton of people willing to do the other i would be a lot more inclined to not do evolutionary. Getting a limited GEAS working might also encourage more people to get involved - they will be encouraged at the potential and more willing to code object transparency. Neil said but as a business developer I can not use forms - its not productive enough. There are too many peices that have to be manually spliced togeher . He noted there is no way to define the business concept and tie it together so it can be discussed - I have to have someone that understand SQL, XML etc then they have to understand how they relate to each other and how the system works.

James said that the GTRiggerNSObject already within GNUe Common might be the start of a object interface to forms. Jason said this was the point of it even as of time of writing - forms is an object-based UI that is currently using a relational backend. He emphasised forms knows NOTHING about SQL... it simply talks to an object provided by gnue-common. James said this object could be extended to expose a getGFD() in geas - then using that to build the UI on the fly [...] doing this would keep the objects on geas. In fact, GTriggerNSObject could easily become GEASObject. Derek confirmed this would let you either grab GEAS objects and methods or let you tie hardcoded methods to GEAS objects or tie hardcoded functions to gnue objects - the last being what it alrady did in 2-tier, and which would mean 2-tier would still be supported.

After checking various people's availability by private e-mail, Derek announced on the mailing list: There have been many disparate talks about the future of GEAS (GNUe Application Server) and where it his headed and how it plays in the overall GNUe architecture. We will be meeting on irc at irc.openprojects.net #gnuenterprise on the following day/time: Thursday Feb 28th GMT 19:00 - 23:00 Anyone having an opinion or wishing to discuss should show up there. . This would probably need to be moderatated, and should last for about 1.5 hours.

The next day, as part of a general GEAS bug discussion, Reinhard explained the background to the current problems. We got this contributed from a company that wrote geas for their own needs - we decided to take it and adapt it to our needs - however we found out it is a PITA - and last week we finally decided to do a rewrite from scratch . He added we are working on a whitepaper and there is a drawing on the website.

Derek Neighbors said that my mission this weekend is to get gnue debs that work. He wasn't keen on doing Debian packages with autoconf - i dont want ot do it the C way - i want to do it the python way :). Daniel Baumann (chillywilly) said it's justa macro language - nothing tlang specific about it. Derek said he didn't want to make autoconf a dependancy for GNUe in general, but he WOULD accept having to have autoconf to make debian packages.

Jeff Bailey (jbailey) said he would do some Debian packages - I just need to get a working copy of GnuE on my system so that I can make sure I don't break anything. Derek said that to make a debian shouldnt require changing the source code of a program (or so i would think). Jeff said It depends on if any locations are hardcoded. Some of Debian's filesystem rules are a little twisted. Derek said this shouldn't be a problem. He was keen to get working debs in the pool by sunday night for 'political' reasons. He asked do you know how to get the source that made those debs? i.e. if apt-get source gnue-forms works and gets the files necessary to actually create the .deb file we are 90% done - all we have to do is find out WHAT is breaking when you apt-get install gnue-forms for example and fix that. Daniel did a quick apt-get and reported looks like it installs for me home billy. Derek said it may INSTALL - does it WORK? He said we have gotten NUMEROUS reports that it doesnt 'work' - however we DID have people file bugs in debian. Jeff said there was nothing shown in the Debian bug tracking system. He said Your reason for not being in woody so far is that you're not building on all the arch's. That should be trivial to fix. Jason Cater (jcater) wondered why - could it be a dependency that doesn't build that's keeping us back?. Jeff confirmed that, although he wasn't the package maintainer, he had access to maintain them as a NMU - Non-maintainer upload..

Jeff later reported that he got the gnue-forms debian package installed - Incidentally, the only install problem I experiences was a conflict with pyxml - That's a broken python dependancy, not a gnue problem. This did not install the demo forms, however. He noted Ah, joy. gnue-forms failed to compile on *every* arch. That's almost certainly a build-deps problem. Digging further, he noted I think that he didn't reazlie that Depends aren't necessarily filled for build-deps.. He posted a python traceback error message he got trying to start Forms with the sample intro.gfd. However, there were no Forms experts on hand to take it further.

The next day, Jason apologised for disappearing - my crappy cable connection went down.

Ke Deng asked How do you think of the ERP Standards(such as MRPII standard written by Oliver Wight)? Is it important for GNUe?. Derek Neighbors said standards were important for GNUe, but many standards a. require a fee for membership to give input or b. are vendor creator or used by vendors to neutralize a market. However, GNUe is highly flexible so it could be made to support almost any 'standard' you so desire..

Todd Boyle referred to the ARAP project, which is free, and is not in any way vendor-specific. It is a completely open attempt to observe, or perceive, the needs of every GL in the world, and see what can be done towards an application-neutral standard for general ledger interfaces. He felt that GNUE does not study or comply with any standards, because it takes more time and research, and does not provide the software developer with a positive return on their additional time invested, in most circumstances.. However, this was a reasonable way forward for an open-source project. Neil Tiffin disagreed - Having worked with GNUE for almost 2 years I think the issue is NOT the lack of desire to use standards. I for one would much rather use someone else's prior work in the form of standards instead of trying to create a beast from scratch. However, I have not found an accounting standard that applies to GNUe. There are all sorts of standard that are vying for control of how accounting is done. But I have not found one that is geared for internal systems. Most of the ones mentioned, so far, have been for data interchange and they are not currently practical for high volume transactions internal to a company.. However, he was willing to be enlightened on this.

Todd felt this was fair comment. There were three different areas where standards were being developed:

1. General Ledger standards

The three groups working on General Ledger standards were:

He felt the other two groups were not being open enough about their work, given that the world is not beating down the doors looking for a GL specification.

2. e-business integration standards.

There were a large number of industry specific semantic models being developed. XML-based ones were covered on Robin Cover pages.

3. The Core Components framework.

This was the common metadata architecture that applies the principles of ISO 11179 to the business domain. This was about getting a a single language of business terms to provide the semantic basis (in terms of natural language) for XML schemas or other computer representations of business data.

Zachary Coffin felt that Todd's criticism of XBRL was unfair, and noted that XBRL International has released the *DRAFT* GL taxonomy for public review and comment several times. That's why we have offered it to the world for comment. They had also been co-operating for a year with the UN/CEFACT group. They had tried to work with Todd's group as well, but to no avail. There was more information on XBRL on the web. A wide range of organisations including SMEs, government agencies, non-profit organizations, etc. were members, and they were even opening up a new category of membership, for academics or individuals non-affiliated with a company.

Robert Lemense refuted Todd's comments about him, saying he was not only a champion of ENTREC but a champion of all UN-Standard Messages developed by D14 since 1997. Todd replied that he didn't see why anybody needing a GL interface to their Peachhree or Quickbooks or AccPac should adopt XML Schema just to comply with XBRL's notional standard. Standards like UN CEFACT would become de facto or de jure mandatory for external B2B transactions, which meant that the process of arriving at the standard needed to be as open as possible. The issues were political and economic, not personal.

Later, he returned to the issue of consultation on drafts, and criticised the existing work of Robert's group, and the collaberation with XBRL. He didn't see why we need government involvement to facilitate semantic standards. Many of the standards already issued by Robert's group were not being used, or irrelevant to real users. He didn't feel that there was an authentic "accounting domain" in the whole entire domain of computer technology, or telecommunications that needed a single international standard anyway. There is an internal integration "domain" perhaps. That is EAI, and more recently, BP standards.. He added All of accounting and payments come after the fact of business transactions. They are deterministic. There is no need for today's labor force of at least 20 million people working in accounting and payments. He felt that control of the standards for business semantics by accountants and banks would enable them to perpetuate their role as intermediaries.

Earlier, Derek Neighbors re-iterated his concerns about standards bodies that requires a lofty membership fee to participate and is created by 'vendors' which hurts the little guy ESPECIALLY 'FREE SOFTWARE' developers.. Kenneth Reiszner said These fees can be as high as $65,000/yr [...] None of these fee schedules goes below $5000/yr. even with reduced member participation. The high figures are for big buck firms that probably can spare the change. The more you pay the more "rights" you get. Stan Klein said that Most standards developing organizations (SDO's) require some kind of fee (in addition to the cost of attending meetings) for participation. This could vary from a notional $10 to thousands of dollars, with different grades of membership and influence. There could also be substantial charges for copies of standards documents. He thought that Trying to completely avoid participation fees will likely mean avoiding all standards..

Derek also asked whether the XBRL standards would cover things for peformance metrics or things like balanced scorecard? Also, are you strictly commericial oriented or will you delve into the Public Sector and do things similar to GASBY?. Christopher Brown pointed out that XBRL is all about reporting standards. It doesn't say what fields there ought to be in particular accounting transactions; it instead speaks to how the summary report at the end of the year should get reported. There was also scope for standards on EDI (Electronic Data Interchange), though. Derek said I think even EDI specifications for data transfers will be similar as we will have an EAI tool or even our reporting tool for that matter than can adapt to virtually ANY XML format. The only issue woudl be if GNUe (the ERP) not the tools didnt have the proper fields necessary for the specification. Stan Klein said Most, if not all, standards define behavior as viewed from outside across some kind of interface. The typical approach is that internal implementation is left to the individual implementer. Sometimes it turns out to be easier to implement the external behavior internally, but the ability to provide the external behavior by some kind of translator is almost always maintained.

He concluded the wonderful thing about standards is that there are often so many competing ones to choose from. :-). Peter Dabrowki said that Technology is changing so qickly that applications like SQL-ledger.org could end up as a de facto standard anyway - certainly for small businesses.

Daniel Baumann (chillywilly) asked what the diff is between an inner and outer join as the one postgres guide I was reading was damn confusing. Derek Neighbors (derek) said an inner join only includes rows where BOTH tables are the same - and outer join includes all of either the left or right table and only the matching of the other . Derek gave an example. Jason Cater (jcater) suggested come back tomorrow for "Fun with Unions!". Daniel supposed that SQL included any set operations right - as thats the basis - you have a set with relations, iirc ? Jason said union is a distint join - intersect is the common stuff - minus is what's in #1 and not in #2. He uses oracle's flavor of unions - I'm not sure if their union keywords are SQL92 .

Later, Derek confirmed that 'tuple' was non-standard terminology that postgresql used for a 'row' or a 'record' ;) . Daniel read on and came across concepts like a cross join - inner join on true - does anybody use this shit?. James Thompson (jamest) said i dont - i use where clauses - i'm oldskool.

Malek Hadj-Ali asked where can I get the packages (financial, sales, ...) and how do I install them ?. Derek noted We do not have them completed only some proposals for them. You could author packages like these with the framework today, but currently dont have 'pre-packaged' ones. We are working on them.. Elsewhere, Neil Tiffin noted I would just like to point out that the GNUe Packages screenshot has a significant lead in hits from all other screen shots, I would interpret this to mean that people want packages. Its too bad we cant find a way to get preliminary packages working with the starts that we have.

Arjen Runsink (Suit) asked whether GNUe preferred wxGTK 2.2.9 or 2.3.2 ?. James Thompson (jamest) said we work w/ either , but he personally felt 2.3 was a bit nicer. The main reason for still supporting 2.2 was that the major GNU/Linux distributions didn't have 2.3 yet. Arjen asked shoul wxPython match the subversion number too, or just the minor? James said i had the best luck matching both , although it's hard to find older copies - IIRC you have to go to sourceforge, as the wxpython website only had current versions.

Continuing , Reinhard announced he had prepared a little document summarizing my thoughts and some of the already discussed points at http://www.gnuenterprise.org/~reinhard, and suggested Maybe this document can serve as a starting point for our discussion on thursday, and can be updated after the discussion to be the authoritive documentation on the agreements we reached.. Neil said he thought the technical goal of GEAS was to be a central repository for defining business rules, methods and data that does not require a software developer to adapt to the business. he felt that the suggested GNUe Object Access Translator (GOAT) should be responsible for row security (e.g. a user can only see orders for their own division), but not for form-level security (i.e. users being able to view or enter orders at all). It would also provide object transparency. Meaning that there will not necessarily be a direct relationship between business objects and tables. He wasn't keen on some of the acronyms, and felt that there were several other modules that needed including as well. He also asked Any chance of getting a written or pictorial overview of common prior to the meeting?.

Reinhard said he wasn't keen on the acronyms either and would use them only for internals (e.g. function prefixes or the like). He asked whether we should also name the new incarnation "GEAS" or if we should find another name. This would make it clear that it's a complete rewrite, and it will be clear that previous documents that mention "GEAS" don't relate to that what we are doing now.. However, he couldn't think of another name. Maybe only GNUe Appserver. Derek Neighbors commented The name has always been GNUe Application Server, I say we keep that. . The best way to avoid confusion was just REMOVE the old documentation or archive it off in a hard to find spot. :). This was a branding issue.

Jan Ischebeck (jan_) said that RPC calls involved object reference IDs and asked Should there be a "description" of all objects to check against? Jason Cater (jcater) said we do pass handles for object when using transports that don't support objects natively (i.e., the CORBA driver won't pass around references, but actual objects) - the handle is used to reference a proxy object on the server-side - so this was meant to be transparent to the client and server - at least when using GRPC on both ends. Jan said A gprc is not needed to comunicate with SOAP or XMLRPC. The only function it can have is to be a kind of control. That means to check which parts of an object should be available by RPC and which not. He added If i understand it right, corba needs an IDL file for client and server. So for corba there is the need of an definition of the tranfered classes on both sides, which SOAP and XMLRPC didn't. Derek Neighbors interjected we are not wanting to define every object - merely a wrapper to pass objects back and forth over the transport. Jason said we very much need the grpc file to know what to expose - the client may not need the grpc file but one has to exist. Jan suggested You mean, the grpc file is something like a communication standarization document. Something like a grammar. i.e. people can SPEAK, without everytime looking on it ;) .

Jason agreed, and noted the problem is, grpc is very much in the early planning stage - as in, you saw the first round of my thought process (you poor soul :) - and we really don't have any docs yet. Jan rephrased his original question as Should the incoming request be checked against the GRPC file by the server?. Jason said I hadn't planned on it - but hadn't gotten to that point. Jan said the basic structure you've coded are quite good. I just had to insert some lines to make it working. He would document the discussions as a GNURPC pre alpha draft docu.

James Thompson (jamest) asked what do you think of python? (now that you're using it)? Jan said its horrible... ... im getting more and more addicted ;) He found it much easier to read than other languagues like C. Jason felt it says a lot about python's reablility when jan can figure out grpc :) James thought it says alot about jan's state of mind in comparison to jcater's state of mind and goes and cowers in terror in the closet fearing a world where more that one person thinks like that. Jan said understanding the grpc code was not very difficult. First you have to imagine a donut, .... ;). Jason said jan is right... all the grpc samples are donut related - so you really DO have to think "donuts" Derek hoped that jan isnt under impression that a grpc donut factory will produce EDIBLE donuts :) - he could imagine some interesting help desk calls. Jan said that he had put a sample GNU-RPC donut installation on the web. Jason got all emotional - my baby - she's alive! James tried it out, and got a super glazed! donut.

James Thompson (jamest) asked if forms highlighted the current field being edited....would this be a bad thing? He said my users are complaining about finding the cursor. Possible solutions were block cursor - highlighting - bolding current fields text - enlarging current field a small amount . Jason Cater (jcater) suggested changing background color of current field to a pale yellow??? - ala my label editor in designer. James was worried that color blind people might not notice it . He suggested we can make the highlighting an option in gnue.conf - highlighting=none, colored, bold, foo and so on. Derek supported this, and suggested i think the 'proper' way to denote field of focus is to bold highlight the border of the field with focus - this way text or background isnt 'altered' which can be hard on eyes - but the field appears 'elevated' to distinguish it Jason said I think we can't do that in wx - or that would've been our primary approach :(. Derek said that is why optoin in gnue.conf is great - so when you have pyGTK and pyQT working someday you can make it right easy :).