Following on from , Neil Tiffin said that, although you could step through the result set using the nextRecord() and lastRecord() functions, he felt a random-access getNRecords(startAt=0, number=1) function would be useful as well. Jason Cater said result sets were meant to be a cache of a query-set anyway, so there should be no need to transfer large amounts of data at once, although he feared he was missing the point. Neil's proposal wouldn't be difficult to implement, in any case.

He explained that ResultSets weren't meant to be passed back and forth, per se, between a client and server. ResultSets were more of a local caching mechanism. In n-tier, both the Application Server and the client would have their own ResultSet. He added I am not sure why a database would be requeried during the life of a ResultSet, but if it was, this would create a new ResultSet and reset the Next Record pointer. If Neil was suggesting that GEAS can present the client applications with a ResultSet via CORBA , this would nullify the business rules/objects functionality of GNUe Applications Server (GEAS) - GEAS would, in essence, simply be a caching relational layer.

Neil explained in more detail what he meant. Jason clarified The nextRecord()-type methods are designed for the clients to use against their internally maintained ResultSet - they do not necessarily correspond to the method used by the ResultSet to obtain data from the backend (in your case, the CORBA calls to GEAS.) . The database drivers for 2-tier access already supported a "pre-fetch cache size" that the client can set, and the GEAS n-tier driver would presumably be similar. The client would then use its internal ResultSet cache to display records as required. In 2-tier, you could jump around within the cached result set, but most databases could not support random access in this way, so it wasn't possible to have jumping around between different result sets. However, It would be nice if GEAS supported a jump-ahead cursor -- this would be yet another advantage of using GEAS rather than 2-tier client-server.

Neil also asked whether the definition of "conditions" used to create ResultSets included sorting on the server as well as selecting. Jason explained that GConditions is a tree-like structure that defines, to use your terminology, "selection conditions" of arbitrary complexity. He gave an example of how a GConditions tree mapped into a normal SQL WHERE clause. Sorting definitions could be even easier, as a simple list could be mapped to an ORDER BY clause.

Neil also asked about introspection, saying that if we are planning on making the introspection data just system data objects with standard field names, then I would be very happy. . Jason Cater said he saw two types of introspection:

He explained in detail what functionality there currently was for both, and added By the way, I have described the way DataObjects currently work, not the way they must work. We are definitely open to restructuring our classes if they do not fit GNUe's needs.

Some days later, on IRC, Neil (neilt) asked Reinhard Müller (reinhard) for your take before i proceed further. Reinhard clarified that the GDataObject stuff concerns geas in 2 ways - for Forms to acess GEAS, and for GEAS (possibly) to access the SQL backends. He emphasised that because GDataObject is in any case a client side library [...] between GDataObject and the caller there is no network connection and no corba (in neither case). He added that he was going to be virtually non-existant for the next month so feel free to discuss this topic further with jcater w/o me.

Derek Neighbors (dneighbo) asked Jason Cater (jcater) did you ever get in contact with that nashville fellow? about presenting gnue at his LUG? Jason said there had been no progress on this so far. Derek mused that i might add to our page some stuff though - like a 'have gnue speak at your lug' :) He thought we need to create 1 or 2 powerpoint presentations and canned speeches so we can submit to tradeshows for speaking - as well as for local speaking stuff .

Derek Neighbors (dneighbo) asked about 'datestamp' issues? with DCL. New tickets had the right datestamp to start with, but when they were resolved it converts all dates for ticket to 12 01 1969 - 'cept keeps the dates for the resolution correct. He would go and look at the code if necessary. Jason Cater (jcater) said I don't recall having an issue with this. Derek asked whether you have email notification (watches) turned on? as, at one stage, he had though this was the problem, but its not. In passing, he noted that the e-mail notification of watches was one of the most impressive bits of DCL functionality.

Four days later, Derek discussed the problem with Michael Dean (mdean). He wondered if its a postgresql 6.5ism - as all the samples i can get to work are 7.x. Michael thought the problem could lie in the Edit() method of dbTickets. Derek said that was where he had applied his temporary fix, but there were still some minor formatting issues. Michael said the date problems were probably because pgsql 6.x used a non-ansi format for those - had a bunch of junk in it (at least from php's perspective). pgsql 7.x converted to ansi format, which is actually parseable. .

Derek commented that this had been a practical example of the benefits of access to the source code - i could look at this and in about an hour trace through to what what going on and pin it down to the edit call - and patch it (ungracefully). I think this impressed the boss - he is still not liking 'unsupported software' much - but seeing problems get fixed quickly makes him smile.

Daniel Baumann (chillywilly) h-reffed to http://sourceforge.net/projects/prevayler, which claimed to be 'Orders of magnitude FASTER and SIMPLER than a DBMS. Write PLAIN JAVA classes: no pre or post-processing required; runs on any VM; no inheritance from base-class required. Clear documentation and demo included. Ready to use.' He felt this is only for the real object heads ;) It was written in Java, but 'can use any language for which you are able to find or build a serialization mechanism' or where you could just output specific memory segments. He noted damn no irc channel for the project - at least not on here..

Reinhard Müller (reinhard) said he was not sure if it is really something new - imho it's nothing more than a readahead object cache with a readahead rate of 100% or so. Nick Rusnov (nickr) felt for what ammteurs use most rdbms for nowadays it'd be good though.

Daniel said a big system would need a ton o ram, but the project web page admitted as much. Reinhard wondered how long a large system would take to start. Daniel said you wouldn't have to start it...it would be always running unless youlost power, in which case you could restore it from back-up and redo the commands in the commdn log. However, for this, your objects need to be deterministic . The discussion moved on to how non-deterministic (quantum or random?) objects would work.

Andrew Mitchell (ajmitch) said he was trying to figure out how to package up an app with python, wxpython, and that inno setup prog :) Jason Cater (jcater) said you first have to package the app in mcmillan - then use inno to install this mcmillan-ized package. There were sample inno and McMillan config files in GNUe's CVS. He explained that McMillan basically turns a python app into a freestanding application - i.e., for windows, it turns gnuef.py into gnuef.exe. This would include python itself. It worked for operating systems other than Windows, but that was all he personally had ever used it for.

Derek Neighbors (dneighbo) suggested adding exclusive list boxes to GNUe Forms. He had come across several examples where he could have usefully used something like this. Jason Cater (jcater) asked what does something like this fall back to when the underlying UI doesn't support it? He supported jamest's philosophy that we aren't creating a widget set to cover all eventualities (as expressed in ).

Derek said that he supported the idea of a 'base' widget set that is lightweight and easily portable to say WAP, Web, Curses, GUI's etc etc, but felt there was also a place for some more complex widgets to make more competitive pieces but might only work on certain UI's. There was already a precedent in the way that the text-only UIs treated images - in curses mode i just 'ignore' it. He added that extra widgets like trees (as mentioned in - while you all might say just eye candy - can make an application infinitely more easy to use. Jason said that he didn't have a problem with things like image (non-)support, but data manipulation-type things must be able to fall back to something useful.

Later on, Charles Rouzer (Mr_You) raised the wider issue of if GNUe provides a small set of widgets, how are users suppose to expand upon this?. Derek said people can add widgets if they like - they just might not be 'supported'. Some non-standard widgets could even be in forms out of box but would never be used in the base distribution of gnue apps. He felt that getting usable applications was more important than getting bunches of widgets :) - i think you can do 90% of what you need with the widgets we have. Jason said that, in principle, a new widget would just be a new python package, but for technical reasons it could get messier than that. Derek said that like ALL free software projects, there was nothing stopping developers adding whatever they wanted, and creating a branch if necessary. In practice, GNUe would often take the patch, though we might state its not a good thing to use it if you want your applications to be in gnue - also if the maintainer stopped maintaining it we would probably drop it or deem its BROKEN. Alternatively, we may find we like some of the new widgets and might be willing to support them even if the original author or others wont. Later, Charles suggested maybe you could have widget definitions embedded in gfd files in the future? However, it was not clear how this would work, and several people felt it was a bad idea anyway.

Elsewhere, Daniel Baumann (chillywilly) said that the big pciture would be if someone actually had an xml gui definition that anyone could implement for whatever toolkit. Derek said there is xforms which i htink is kind of what you are wanting... but said that GNUe Forms Definitions (.gfd) were a sort of standard anyway, as people could write their own GNUe Forms clients - there had already been some examples of this. He felt that standards that were actually in use giving people practical benefits were better than 'paper' standards that never got used.

The next day, Peter Sullivan (psu) said he didn't see why Derek's proposed widget couldn't work in text . Jason asked how would it work in html? - the page would have to be refreshed after each selection. Peter asked How do we feel about javascript in HTML clients?. This would shift work from the server to the client. Jason said I would like to see a basic html client that worked under lynx and everything else - but could see an enhanced html driver that made it more "friendly " to use, but required a more modern browswer. He also said GNUe might need to work with something as basic as a line-oriented forms client in which curses support isn't there - it basically displays one question/line at a time. Peter said Derek's proposed widget could be done as a Q & A script - it would be hideous, but pretty much everything in line based would have to be.

Derek (derek) said that there is a free implementatoin of 'java script' iirc [...] i think its called spidermonkey. He didn't see much value in lynx support - we have curses across the web if someone wants that. He said i think webclients will pretty much have to support some language or it will be painful - as you will be sumbitting forms like crazy for the most trivial of things. Jason said that support for non-script browsers was important as a lot of ppl still use old browsers and a lot of ppl (like me!) disable JS support, etc Also, It's a implementation test for us... basically, keep us truthful to our abstraction :)

Following on from , Peter Sullivan (psu) said If we can solve the issues of distributing client code , HTML forms would be less important. Derek Neighbors (derek) said that differences between browsers were a significant issue - in most environments, putting the client binaries in shared location and the gfd's in shared location means clientless maintenance anyhow. Peter said that if all the apps logic is in GEAS you don't have to upgrade GNUe Forms client as often - but you will still have to occasionally? Jason Cater (jcater) said we use shared binaries - which solves part of the problem. In one office, this was done by using Linux Terminal Server (LTSP). Peter also noted that at the moment, you can network install GNUe Forms. Both Jason and Derek said that was a requirement - Derek said maintenance ease is at top of list. Peter said that the Problem is that people assume that web-based is the only way to resolve client code distro problem, and referred to a British government paper on the subject.

Jason said who knows, we may have self-updating forms clients someday :) Perry Lorier (Isomer) said client side code is very nice in the general case, but he was worried about security issues - While you can limit them with the client to certain abilities, you can't necessarily stop them connecting with access via ODBC then doing a "DELETE FROM table". He felt self-updating Forms clients could become a target for trojans or exploits. He agreed that a simple way of doing upgrades is a good idea [...] but make sure it does smart things like check a signature on the file. He gave some real-world and theoretical examples of automatic update sites being cracked. Peter said he felt the concept of a "mandatory upgrade" for free s/w is an oxymoron. However, once an enterprise had conciously decided to accept an upgrade, they need the tools to distribute that fix as easily/quickly within their enterprise as possible.

Further to , Michael Maluck (madlocke) asked about the User Interface re-write of GNUe Forms, and how it would impact the HTML GNUe Forms client he was writing. James Thompson (jamest) said it's really just cleaning things up and making it play nice with your stuff . Michael said what i am doing now is a different way of linking objects and integrate a layout manager... some parts work already... want to show it to you after i added a few more things. He said you could now use either x,y coordinates and layout manager He explained the creation of objects will be much more transparent - und separation between uibase und wxpython is more clean. James asked can you put in cvs? and does it break lots of stuff Michael said he would CVS it tomorrow . James asked is this working with the wxPython driver as well? Michael confirmed this had been re-written. He also wanted to get rid of this phase init stuff.... James said they had tried that, but kept having to kludge in work arrounds . Michael suggested the main reason for phase init is because you don't have all information at time for object creation that is needed. right? James said yes - but it's not just at the UI level . Database connections were also an issue. Michael said first thing i'll do is visual stuff, then look at the parser again. He should have the time to work on it now.

Michael Maluck (madlocke) reported i have some ugly problems with wxpython.. James Thompson (jamest) said the wxpython layout managers weren't very stable/usable yet. Michael said he might have to write his own. James said wxpython had issues in several areas - but we get a lot of bang for the buck in having a wxpython driver Michael asked if tkinter had been considered. James said i did some work in tcl/tk and quickly grew to dislike it. Bill Hamilton (Bill_H) said he had written some really powerful, readable code in just a few lines with it. Derek Neighbors (dnwork) said he thought wxPython was the best python UI out there assuming you want to EASILY maintian portablity - the issues it has are minor in comparision to the features it has, and were mainly with newer functionality.