Reinhard Müller (reinhard) had been playing around with dynamic menus lately. Currently you can have <menu> and <menuitem> tags in your GNUe Form Definition file (.gfd) that are added to the main menu. But we've once talked about making it possible to replace/hide standard menu items by putting some magic in the gfd. So I thought about introducing a config file with the xml code of the standard menu and the standard toolbar - which would be merged with the menu given in the gfd, with the .gfd version taking priority over the config file's defaults. This would allow both the standard menu items, plus any additional menu items specific to that form, to be merged into a single XML tree In fact, he confessed the starting point was common handling of standard menu and custom menu as well as "not hardcoding things" for the standard menu - and being able to site-customize menus is only an interesting side effect. James Thompson (jamest) did not see a problem putting it in a file and I could see some advantages.

Reinhard Müller (reinhard) noted that there was no ready-to-go permission management yet - I guess you could build something with triggers, although built-in permission management is on the todo list, but with lower priority.

Reinhard said that what he liked about GNUe was that it is still the only way I know that gives you platform independence *and* backend independence at the same time - you could use it with any operating system and any database - and it is 100% free software. About the only negative was that GNUe was still not yet 1.0 if you understand what I mean - there might be some features missing, but what's normally needed is there - and we have seen other projects calling 1.0 what we would have called 0.4 ;-).

Later, Reinhard noted that, although there was a Developer's Introduction, there wasn't really a seperate Getting Started document. some people have written up something in the wiki, but most of that is not current anymore AFAICT - the problem with such a getting started document is that 95% of what you do depends on platform, database used, and what you are aiming at at all - so it is very hard to write a generic howto.

James Thompson (jamest) noted i'm running 30 person call center w/ gnue based apps - but we're an LTSP shop. He had three medium-sized servers and people pick their login machine at startup all of which run kde + a java app + gnue based apps for multiple people - the machine I'm logged into now has 8 people using it as of time of writing. There was also a seperate, slightly larger, server containing the postgresql DB. This meant that if one of the LTSP servers locks up or the hardware fails only the users logged into that box are effected - they reset their ltsp terminal and the process is repeated with less machines avail. I've blown a NIC and left the machine offline for a few weeks without issue. I also run one machine as our test login box. Users are welcome to use it like any other but i'll initially install new stuff there - and if issues arrise (say a new version of gnue breaks 2 or 3 forms only 1 person uses) then that person avoids the test box - until I resolve the issue, they test again, and the updates are pushed to all machines. He commented this setup works really well for us - as our login servers aren't high end, our terminals are $50 old dells or compaqs purchased from a reseller - it's a poor mans high availability for a call center :).

It was asked how the Application server sent data to the client. Bajusz Tamás (btami) said that data for the form on the client was sent using xml-rpc. Reinhard explained gnue-forms calls a RPC function on appserver, then appserver sends the form as the function result. However, the server did not refresh data in the form if it changes - in fact clients work in isolated transactions - i.e. you don't see changes made by other clients unless you explicitly commit or refresh your transaction - which is, BTW, how I really think it should be.

Derek Neighbors (derek) asked has there been any more work done a on a web client by siesel? Jan Ischebeck (siesel) said it is kind of stalled at the moment, as I #ve been occupied with real life - But I will have really much time in July - and have already many ideas, how to improve the webclient. Derek said that currently we are using a lot of ruby on rails - i think it does a lot of things well, but it still doesnt solve my primary problems :) He noted they have something like gnue designer wizards (only for web) called scaffolding that is interesting - and their active record stuff is similar to gnue-common. Certainly RoR has brought web applications very much into the future but it still misses the mark to be a specific enough framework to churn out enterprise applications. Jan said recently I read a comparison between RoR and Zope. Both would be application frameworks, which would promote a programming language. And users would learn first about the framework and then start to use the language. Derek felt that was fair - there is much talk about how pretty and perfect ruby is.... but personally it reminds me of perl - only with a good object model - of course i liked object pascal so what do i know? He added dont get me wrong, ruby is really quite nice, but i dont think it this elegant thing of beauty people claim it to be - simply put, w/o rails i wouldnt be using ruby. Dmitry Sorokin (dimas) suggested then take replacement for ror from python's world.

Jan said that his idea of an enterprise app framework is to use gnue-designer + vi to create the forms and reports and try it out using gnue-forms as a normal client-server application - and then to transform it into a web application.