Hello James, Youngjin, hello *, thank you for your replies.
Most important for us is the question regarding next steps. How can we share our stuff with the community? Is there a special process / requirements to get involved into the Etch project? How can we make our source code available? Scott, are you the right to answer this question? James, it would be nice if you could go more into detail regarding the significant challenges which you mentioned. Of course we read the notes supplied with the c binding and worked on some of those, too. To go more into detail on our work: - we added a first compiler implementation using velocity (like the existing one for Java). The generated source is inspired by the example source code for the "perf" application (but of course supporting all etch features, and not only the ones present in "perf") - ported the source to Linux / Unix (required some refactorings due to compiler differences and some operating system specific code) - we analyzed the code using a thread analyzer and removed some race conditions and deadlocks - we removed the hashtable based memory allocation code (due to multithreading issues) and used a runtime heap checking library instead - removed some memory leaks - startup code for client and server is refactored - added a configuration mechanism (either using property files or direct calls) - logging code was refactored to support different appenders (customizable using above mechanism) - re-wrote the mutex & condition variables implementation - Unicode conversion code was refactored to be operatig system independent (using apr-iconv) - refactored the test suite and added some tests - refactored global variable initialisation and lifecycle management - refactoring of some namings in the runtime code - added support for custom exceptions - serializers for some types, e.g. list, set and map were refactored (they now work exactly as in the Java binding -> all are sent as Object[]) - structured the headers and c files, removed some unused ones - some general bugfixing and cleanup for runtime code Looking forward to your answer, Holger Grandy Michael Fitzner Youngjin Park (youngjpa) wrote: > > Hi James, > > I also like to get some assistance after I look into the current codes. > I have a plan to spend time for C-binding. > > Hi Michael and Holder, > > It is good news. I hope that we can split some of works together for > C-binding. If you can check in yours soon, I can also start developing > on the top of the check-in. > > Thanks > > Youngjin > > -----Original Message----- > From: James deCocq [mailto:[email protected]] > Sent: Monday, January 11, 2010 8:49 PM > To: [email protected] > Cc: [email protected] > Subject: RE: Etch C Binding Implementation (Compiler + Runtime) > > > > Hello Michael and Holder, > As the author of the original C code, I could perhaps be of some > assistance. In particular, there were a few significant challenges to be > resolved, perhaps you identified these and did so. > James deCocq > >> From: [email protected] >> To: [email protected] >> CC: [email protected] >> Date: Mon, 11 Jan 2010 18:45:28 +0100 >> Subject: Etch C Binding Implementation (Compiler + Runtime) >> >> Hi everybody, >> >> we evaluated the Etch SDK several months ago and we think that it is a > quite good RPC mechanism for our specific needs. Since we need a fully > functional C binding, we checked out the source. We could not yet > participate in the community in the last months, but for us this was no > reason not to look into the source code. So we started implementing the > C binding. >> >> At the moment we have implemented a functional C Compiler for the Etch > IDL and worked a lot on bugfixing and finalising the C Runtime Code for > Etch. RPC calls with nearly all of the Etch features (both in client and > server direction) are working with fully generated code from the > Compiler. Some stuff (like e.g. @Authorize) is not yet done, but all > core features work. >> >> Current state is early beta in our opinion, our Compiler-generated C > code works for our IDL test suite and the existing Etch runtime test > suite is running, too. >> >> We did a refactoring of the existing C runtime source code of Etch. We > did not change the basic architecture, but structurized and cleaned the > source and enhanced/re-implemented some features, like source for > startup and configuration, for logging, parts of the threading source, > for the test suites and some others. >> >> We also did some bugfixing, e.g. related to multi threading race > conditions and some others. >> >> We ported the source code to Unix based systems. >> >> Our intention is definitely to participate in the Etch community. We > want to get in contact and hope that this will be of good use for the > Etch community and that our efforts will find their way into the Etch > codebase. It is possible for us to submit our source code back to the > community, but the timeframe for this is not yet clear. A discussion > regarding this topic would be very welcome. >> >> We would of course be very happy if our efforts would bring the whole > project one step further. >> >> Sincerely, >> Michael Fitzner ([email protected]) and >> Holger Grandy ([email protected]) >> >> BMW Car IT GmbH >> > > _________________________________________________________________ > Hotmail: Powerful Free email with security by Microsoft. > http://clk.atdmt.com/GBL/go/196390710/direct/01/ > > -- View this message in context: http://n2.nabble.com/Etch-C-Binding-Implementation-Compiler-Runtime-tp4287753p4391168.html Sent from the etch-dev mailing list archive at Nabble.com.
