GNUe Traffic #5 For 1 Dec 2001

A lot of people tell me, when I say we need volunteers, the following: "I wanted to volunteer for GNU and/or for the FSF, and thought I wasn't good enough." I tell them that we're just a bunch of programmers and concerned citizens --- no need be a famous computer scientist to get involved.

Kissin' Cousins:This particular issue also covers an irc discussion held between the GNUe team and the project teams for dotgnu, gnue, gnucomm, dcl, and phpgroupware, to discuss joint issues. This discussion started on #gnuenterprise, but moved over to #gnuproject. The log for the #gnuproject part is currently at http://goats.gnue.org/~chillywilly/gnuproject.log.

Aditya Gilra outlined the extensive changes needed to GNUe Forms to get it to handle "Hindi(Devanagari) characters" . However, these would no longer be necessary once Gtk2.0 was used. James Thompson said "Actually this isn't just a local problem. We need much better i18n support thoughout the code. I would love to see the unicode work you've done and see about folding it into cvs." Aditya said he would "try with 0.1.0 and pass on my changes if they can be of help." Dmitry Soroking said UTF8 encoding was an issue for him as well, and added "There is initial support for dealing with database encoding" in the drivers for pypgsql and postgresql. Aditya agreed that UTF8 encoding was an important issue, and reported that " while trying out GTK+2.0 (GTK+1.3.9) the text widgets do seem to take in and give out utf-8." He added "Using unicode does make the client a bit slower though."

Meanwhile, on IRC, Derek Neighbors (derek) said he had been planning to start on an application using GNUe "and gnue designer is completely jacked" . He wondered if it was because he was using "the newest python and wxWindows" . Reinhard Müller (reinhard) said it "looks to me like a i18n issue - bug in 2-byte char handling or like that - every second byte is NULL" .

Three days later, Derek outlined his problem to Jason Cater. Jason said "I think it's storing it in unicode " , and added "btw, this could be a good thing if I can figure out how you did this! :) as it solves a few of our i18n designer problems" . Derek and Jason discussed possible issues around the correct version of python needed.

For previous related discussions, see Issue #3, Section #2 (8 Nov 2001: Using GNUe Forms with non-latin character sets) .

Daniel Baumann said "We are looking at possibly implementing the ODMG spec in the application server" , and asked about freedom/licensing issues. Douglas Barry replied "The ODMG specification is free for your use. It is not proprietary and is not patented. Also, the ODMG specification is not available for purchase as a product from the ODMG. The specification is available in a book from Morgan Kaufmann Publishers for anyone to implement. We do ask that you mention the ODMG specification if you use it." He also mentioned the Java Data Objects (JDO) specification as an alternative.

Michael Maluck (madlocke) raised the issue of message handling, both for GNUe Forms and the rest of GNUe, including GNUe Application Server (GEAS). He asked "are you satisfied in the way geas does it?" Derek Neighbors (derek) said "No, I'm not satifisfied with it and there is no document - message handling IMHO should be in GNUe Common so that all parts of the system reuse it" . Michael Maluck agreed and asked if this had been discussed in detail before - if not, he would work up a proposal. Michael Brown (mcb30) suggested "look at gnue-common/doc/GCommSpecifications.txt" , but Derek said that only covered "RPC transport" .

Cyril Bouthors (CyrilB) reported that " Several images on the gnuenterprise.org website seems to be made with non-free Adobe software" . Reinhard Müller (reinhard) said "we accept contributions without regarding what tools were used to do the work" . This was especially true of documentation, which was always in short supply for GNU projects. The key issue was that "the format itself isn't proprietary, and it can be viewed without proprietary programs" He added "if you want to redo those pictures in dia (or whatever) we will gladly take it." Cyril agreed that the graphic itself was a PNG, and hence viewable by free software. But "You can consider this PNG as a binary distrubution of the contrib, not the source code. We NEED to be able to modify the code." Reinhard said he would prefer that the diagram was maintained in a free tool, and emphasised that using Adobe was a temporary solution. Neil Tiffin (neilt) said "any program that reads png which is a standard format can edit the graphics" - as far as he was aware, "png is a vector format graphic, so all vector information is in the version on the web" . Reinhard said that http://www.libpng.org/pub/png/ implied PNG was a pixel-based format like GIF or JPEG. Although the graphic could theoretically be edited in a pixel-based graphic editor, this would be inconvenient. Cyril said "friends of mine are using dia and xfig for this kind of graphics." Neither Neil or Reinhard were keen on dia, but Neil installed xfig to see how it worked. He added "I would use dia, as soon as someone provides a way to convert dia diagrams into our gcd format" . It could then be used as a graphical front-end for designing .gcd files.

The next day, Derek Neighbors (derek) clarified "I dont care what tools another developer uses as long as with no fuss I can use free tools - for example if i write something in C++ it doesnt matter to me if someone else wants to use Borland CBuilder as long as prop extensions and files are not used to prevent me from using gcc" - the same principle applied to images.

For previous related discussions, see Issue #4, Section #4 (14 Nov 2001: Using non-free tools for GNUe Documentation) .

Derek Neighbors (dneighbo) suggested including "introspection on widgets" . Native CVS support would also be nice. Also, "currently if you open a form etc it opens a whole new instance of designer" He said "it would be better if we could make the code window where the form is and make the form floating like the property editor and code window" . He admitted this would be a lot of work. James Thompson (jamest) said "I vote that's a post 0.3.0 release feature :)"

Derek Neighbors was talking about some real-world databases he was converting to GNUe, and said that the lack of native grid support was a problem. "While the multi row entries work they are not the best solution" . Jason Cater (jcater) said this would have to wait until the User Interface re-write, but that "is what's next, IIRC" . Derek added "I'm also needing image support soon for something I'm toying with" .

James Thompson (jamest) reported that " gnue-forms list is broken" . Derek Neighbors (dneighbo) said he was "wondering if we are best off just consolidating the names of people on the lists to the main gnu.org list and ditching the others - I like having several, but we are not using enough - as I think we are more effective via irc" . James suggested having just two lists - gnue and gnue-announce.

For previous related discussions, see Issue #2, Section #21 (6 Nov 2001: Website redesign and mailing lists) .

Derek Neighbors said "we have kick ass solution for UPS" . It was fully integrated, "so you never key ANYTHING for UPS - its all automated - realtime - even verfying packages arrived :)" This had been done for Liberty Distribution Corporation, and had been Derek's first involvement in GNUe.

Derek Neighbors (dneighbo) did some quick benchmarks of GNUe Forms on "dbserver: p233mmx 64mb ram (rh6.2, postgres6.5) client: p200mmx 64mb ram (debian unstable, python2.1)" . Loading the form first time took 24 seconds, but only 7 seconds the second time. Querying back 10,000 records took 3-4 seconds. He reckoned "a 20k record db with 10 or so columns is gonna be about 3-5 sec on this machine - and navigating records is near transparent - not like a lag to roll through the result set" .

People started arriving from other IRC channels for the pre-arranged meeting. Derek Neighbors (dneighbo) said "we had discussed possibly doing this completely open" . Bradley Kuhn (bkuhn) said "I'd like to do it in an open way, as long as the traffic doesn't become unbearable." It didn't really matter whether the discussion was on #gnuproject or #gnuenterprise, although #gnuenterprise had a more reliable logging mechanism. Derek said "It would be nice for the GNU project as a whole to have a meeting like this minimally once a month - just to get the maintainers in same room and see where paths collide - and projects that are working together to show the fruit" Bradley said "That's probably impossible, but I do think the GNU project as a whole should have an annual meeting." They discussed what the meeting scheduled for later on would cover, and considered postponing it. Bradley said "so, really, this is a " DotGNU and GNU Enterprise" meeting, since they are going to merge." . Derek said that is what he wanted to discuss, as "I dont see how groupware and dotGNU can merge into a 'project' - I see how phpGroupWare could adopt 'dotGNU' for part of it - but really dotGNU is protocols not an application." He continued "In essence I don't believe groupware standards belong in the dotGNU spec" . Bradley thought "phpGroupware fits well as a part of DotGNU because one of the key things the DotGNU folks are trying to do is services of all different types. DotGNU is probably going to be a big tent, in the same way GNU Enterprise is" . Derek said "if they say groupware is one of the first apps they wish to write using dotGNU then i think that makes sense :)" . Derek explained the distinction between GNUe Tools and GNUe Applications. Bradley said the DotGNU project had the same sort of concept, "although the project is young enough that they don't have clear names for the parts yet."

Daniel Baumann (chillywilly) did some mock hero-worship of Bradley - "da man!" , or at any rate, "da man's right hand man" . Bradley appreciated the joke, but said hero-worship could sometimes be an obstacle - "A lot of people tell me, when I say we need volunteers, the following: "I wanted to volunteer for GNU and/or for the FSF, and thought I wasn't good enough." I tell them that we're just a bunch of programmers and concerned citizens --- no need be a famous computer scientist to get involved. "

Daniel asked Bradley what he thought of his e-mail about "dotgnu/GNUe intergration and what can be shared between the app server and dotgnu "middleware"" . Bradley said the important thing was sharing protocols, not necessarily code. Daniel said he was "tryin to keep one foot in each place anyway :)" He said he thought GNUComm or equivalent could be "more than an PRC abstraction layer, but a "middleware glue" - we can make it generic enough for anyone to use it in place of regualr old corba or soap" .

Derek Neighbors (dneighbo) chaged the topic on #gnuenterprise to "The GNU Project - Meeting of the Minds - As Feeble As They May Be" . As everyone introduced themselves, Bradley Kuhn (bkuhn) said "The main reason that I wanted to have this meeting is so we can have a discussion about how interfaces between GNU applications that have overlapping target sets can work together. Not by necessarily sharing code (although that's helpful when it works), but by agreeing on protocols." Derek noted the projects involved:

The intention was "to see where vision and architecture intersect" . He asked for a quick overview of the dotGNU vision. Norbert Bollow (nb) said Microsoft .NET was trying to lock people in. "DotGNU is about doing just the opposite... Meeting the same technical needs with webservices and stuff... but in a way that users / customers can be sure that they can't get locked in." DotGNU didn't necessarily have to match everything in Microsoft .NET one-on-one, "But we must provide all of those building blocks." David Sugar (dyfet) clarified that the intention was to be interoperable with Microsoft .NET "where standards compliance exist [...] but not where it either compromises commercial integrety or security." Norbert added "Also we can do things that Microsoft won't, like support both C# and Java."

Michael Dean (mdean) said "I'm not aware of a relationship " between DCL and Savannah at the time of writing. Derek said the GNUe project "is looking to use dcl in place of savannah " internally. Michael said "DCL needs some more features implemented before I would consider it in such an environment, but it is within the scope of the project" .

Derek clarified the pre-existing links between the participating projects - "gnue and dcl have relationship - phpgroupware and dcl have relationship - phpgw and dotgnu have relationship" . David said "There is also a developing relationship between GNUCOMM and phpGW that may be worth touching upon" . Michael clarified that if DCL "detects that it is part of a phpgw installation, it defers to phpGW's UI handling (page rendering mostly)" - there was no code sharing. Bradley asked if Michael would "submit dcl to be officially a GNU program?" . Michael asked for details of the procedure to be e-mailed to him.

we have been facing RPC issues, i.e. which to use, and have started a library to abstract this, there could be shared value here
Groupware standards, we see HUGE value in GNU setting standards that are implementation free, i.e. just like html has a standard and anyone can write a browser, doing same for groupware, and other items
Authentication, we see lots of overlap in projects trying to do authentication, the key is it needs to be flexible and not highly complicated to implement
RBAC - role based access control - this is the 'second part' to security at a process level, key for business applications also see shared value
workflow - shared workflow component would be nice or at least API or such

Bradley said he thought 2. and 1. were the most important "and 3, 4, 5 might fall out in the wash when we come to consensus on 2,1." He said "the groupware standards need to define what ways RPC is going to happen." Derek disagreed - "the group ware standard should have ZERO to do with implementation" . Groupware specifications should be architecture independant. Bradley said he agreed - "It should be possible to write to the groupware specs without a specific RPC implementaiton in mind. But, I think amoung the groups in question, it would be good to have a "decided upon" default way of doing."

Jason Cater (jcater) explained how the GNUe Common package was intended to be "an abstraction layer for various RPC methods - be it CORBA, XML-RPC, SOAP, etc" He continued " Our goal is to write a lightweight wrapper around all of these that will allow us to add new methods as time goes on" David said this fitted in with what was going on in DotGNU " and also it would be very useful in GNUCOMM right now... " Bradley said "one of the concerns that I would have is that this has been tried so many times and had major drawbacks. I am thinking particularly of Bonobo, which is so hard to use." Derek said this was different - "they have goal of trying to change industry - we have goal of trying to unify it" Norbert suggested Jabber As Middleware (JAM) - "a variation of the Jabber protocol which has stalled, and which the proponents are trying to revive by selling DotGNU on it :-)" Derek and Jason said the advantedge of an abstraction layer was that it was easier to adapt it as new/better transport mechanisms came along. Derek said "we have need for this regardless and are willing to write it (in fact we have started already) - we would love to share it and make it usable by all" . James Thompson (jamest) clarified that "it's python only at this time" - Jason said the python version was really "a proof of concept/reference implementation" . Derek said it should be easy to convert the python module to C, if performance was an issue. Dan Kuykendall (Seek3r) pointed out "All of this needs to be language independant anyways." Bradley agreed, saying the issue was that "what gnuE is doing in this regard is simply not incompatible with what other projects are doing, since the other projects (DotGNU, phpGroupware) are planning to support XML-RPC, SOAP, or a protocal like that." Derek and Norbert said both their projects wanted to support as many protocols as possible. It was felt GNUe Common should be renamed (possibly to GNU-RPC), to avoid confusion with the GNUComm project, as previously suggested in Issue #1, Section #2 (24 Oct 2001: GNUe Common vs. GNU Comm project) .

It was asked how an abstraction layer could work if it didn't know what the methods were written in. Jason said "the layer does not care about your methods - it just needs to know what they are" . Daniel asked "how can you amke an abstarction layer that talk to stuff without knowing what methods to call" . IDL could be used for that. Derek tried to clarify if the other projects were interested in a common library (i.e. shared code) or just common standards. Several people felt the discussion was fragmenting, and it was agreed to move to the #gnuproject channel and discuss this further.

On #gnuproject, Bradley changed the topic to " RPC Compatibility for Related GNU projects" . Derek explained it would be like a "database abstraction only for rpc" . Dan thought this was ambitious, due to the need to support multiple languages. Derek, Michael and Jason agreed it was ambitious, but not impossible. The other projects would not have to use the common RPC broker, but could offer it as an option. Bradley proposed "GNUe might as well give this idea a try. and, meanwhlie people can use XML-RPC" . Dan said he still had concerns about supporting multiple languages, and "the problem is that if we all work on using this common broker, then we will lose sight of the standard procotols such as xml-rpc and soap" . Bradley and Jason explained that the point of the common RPC broker was that programmers would not have to worry about which protocol was actually in use. Jason and Michael clarified that this was not a new protocol - just a way of abstracting multiple different existing protocols. Dan said they were doing a similar kind of abstraction, but for methods in PHP Groupware with the "ExecMethod()" function, so that the program didn't have to know what the method was actually written in. Derek emphasised "we are only wanting to abstract initially the transport" , not the methods themselves. Bradley said that, even if the attempt to write a common RPC broker failed, "are we any worse off than we were if they hadn't tried?" Jason reiterated GNUe's goal, which was to to seemlessly support as many as possible, not just XML-RPC and SOAP, which were fairly similar anyway.

Bradley summarised. The GNUe project would continue their work on GNUe Common/GNU-RPC, which the other projects would be interested in if it proved feasible. In the meantime, XML-RPC was probably a better choice as a standard for a single protocol than SOAP.

Bradley Kuhn (bkuhn) said that, although co-ordination meetings took time, "the outcome can be good." . Derek Neighbors (derek) suggested "for a while maybe it would be good to set like one a week or every other week - we could make them more publicly announced for people to watch - and then get good input after wards by opening up for discussion" . This could be good PR for all the participating projects. Bradley agreed, but said "I do think that in the future, we should have an agenda and then have only one or two reps from each group. With an agenda, each group can discuss their position on the matter ahead of time, so one rep is possible." Daniel Baumann (chillywilly) suggested a "gnu project" Kernel Cousin. Bradley said a mailing list would also be good. This kind of co-operation between projects was "a challenge the GNU project hasn't faced until now." Derek said a Kernel Cousin could also link to "any other info from gnu projects" such as Richard Stallman's speaking engagements. Bradley pointed out that these were already on the GNU website at /events.html. Norbert Bollow suggested " Maybe call it gnu4biz... a mailing list and correponding website on all GNU projects targeting businesses?"

Bradley Kuhn said "We have been talking about mkaing a GNU IRC server, anyway." Derek Neighbors wondered if this was necessary - "openprojects seems to be pretty good" . Bradley said the word "open" was possibly an issue. Daniel said it was open projects, not open source - "I wouldn't be here if it was the open source network" . Bradley asked if "they would alias freeprojects.net or something to it" , and call it "Free and Open Projects Network". Sometimes people over-reacted when FSF asked things like this. Dan Kuykendall (Seek3r) invited Rob Levin (lilo) from the openprojects.net staff and outlined what had been proposed. Bradley said "Basically, I can probably sell RMS on the idea of adopting your network as the official one, if you use the words "Open " and "Free" equally." Rob "looks mildly ecstatic" . He emphasised that the scope of the service was open as in open disussion and accessible rather than open as in open source. It was pointed out that freeprojects.net, freeprojects.com and freeprojects.org were already registered, but irc.gnu.org could be aliased to openprojects.net, in the same way that irc.gnue.org already was. Jason Cater (jcater) said "I wouldn't think "Open Projects" has any connotations with "Open Source".. that's like saying Oranges are like Orangutans" . Bradley said he would talk to Richard Stallman about it - "he's doesn't comprimse on ethics, but is always willing to comprimse on other things." Derek said "the VALUE of having lots of projects on SAME network is immeasurable" . David Sugar (dyfet) said "Yes, the conference we just had demonstrates this" .

Yurii Rashkovskii (Yurik) asked "why do use ORBit and not any other one in GNUe?" Derek Neighbors (dneighbo) said they preferred ORBit as it was part of GNU, but they were working on GNU-RPC, an abstraction which would allow you to "use ANY ORB you want - or XML-RPC - or SOAP" or whatever. Yurii said his project, " E/AS (Enterprise / Automation System)" , was looking to use omniORB. Derek asked "why not just join gnue?" There was already significant Russian involvement in GNUe, and " Enterprise stuff is such a HUGE task the more people working together rather than apart the better " - unless the architecture issues were irresolvable.

Yurii raised several issues. He said he wasn't a free software fanatic - "I WANT to publish E/AS source under GPL or something like this terms, but it is only license," not a point of principle. Charles Rouzer (Mr_You) said "we have plenty of non-fanatic developers ;-)" Yurii also said E/AS wanted "to build the system using Python from the scratch, using C elsewhere where we need performance (or something else that requires C)" . Jason Cater (jcater) said that was similar to GNUe - except for GNUe Application Server (GEAS), "we are a pure python implementation" . Yurii added "Our model is not an application server. We imagine the whole system is a dynamic distributed object database." Derek said that, if this involved "relational data storage" , then that was all that GEAS was anyway. Yurii explained that the object 'database' in E/AS "can be stored anywhere - RDBMS, DBM, memory, plain disk partition" . Derek said this was the same goal as GNUe - "we just started with relational" Yurii also said they also wanted to do user interface (forms) "in UIML" Jason said GNUe "is UI independent, so a UIML driver could be written" and pointed out UIML was non-free.

Jason suggested "It sounds like you guys are doing an Enterprise Java Beans type of system in Python" Yurii said it was similar to EJB, but "There is no "class" notion. Only objects." If they couldn't do it in python, they would use another language. Jason said, based on his experience, he thought they would find python was "the most helpful w/dynamic objects" . Yurii said they had thought about security issues, but hadn't specified anything yet. He explained in detail how objects would work without class notation. He said "I looked both at Pyro and PyDO. They aren't the system that I've described." Jason asked "Where do business rules fit in" ? Yurii said in simple cases, the system would behave as a normal object-orientated system. But business objects could be branched " (for example, for versions, or something else)" . Jason suggested continuing detailed discussion on the #eas IRC channel.

Daniel Baumann (chillywilly) was looking at the code for GEAS, and asked "a ref is like a pointer to an object?" Neil Tiffin (neilt) confirmed "a reference is a uid of another object" . He pointed out that "in reinhard's new parser the reference and list syntax has changed" . Daniel said he remembered seeing that on the mailing list .


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	18 Nov 2001 - 25 Nov 2001	(7 posts)	Hindi(Devanagari) characters in GNUe Forms
2.	22 Nov 2001 - 23 Nov 2001	(2 posts)	ODMG specificiation in GNUe Application Server
3.	24 Nov 2001		GNUe Common Message Handling
4.	25 Nov 2001		Using free tools for GNUe diagrams
5.	26 Nov 2001		GNUe Designer TODOs
6.	26 Nov 2001		Native Grid Support in GNUe Forms
7.	26 Nov 2001		GNUe Mailing Lists
8.	26 Nov 2001		Integrating GNUe with United Parcel Service (UPS)
9.	26 Nov 2001		Benchmarking GNUe
10.	26 Nov 2001		GNU: The Gathering
11.	26 Nov 2001		The GNU Project - Meeting of the Minds
12.	26 Nov 2001		The GNU Project - Future Meetings?
13.	26 Nov 2001		Free and Open Projects IRC server
14.	27 Nov 2001		Possible co-operation between GNUe and E/AS
15.	28 Nov 2001		References in GNUe Application Server (GEAS)

GNUe Traffic #5 For 1 Dec 2001

By Peter Sullivan