incubator-etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Grandy <Holger.Gra...@bmw-carit.de>
Subject RE: FW: Etch C Binding - how to continue?
Date Fri, 23 Apr 2010 11:37:15 GMT
Hi all, 

it's good to see a discussion happening. 

We stated from the very beginning that we would like to see that our code will 
find its way into the apache etch repository. We do not want this project to fork. 
We hosted our code on github as you know, because at the moment we cannot
check in into the official repository. We didn't want to supply changes 
with several ten thousand lines of code in a jira attachment. 

However, I know that there are other developers besides us that develop for Etch and 
use it. So your community could be there already. We now for example have a pretty good
experience with the Java and (of course) the C Binding for Etch. 

and to answer scott's question:
> > you could start by saying what it is you are looking for, where do you
> > want to go? what's missing? what would be cool?

There are several things, of course from our point of view a functional C binding 
was the most important. We were looking for:
- an open source service implementation, that uses an efficient 
  binary transport (in contrast to e.g. Web Services) 
- that has defined semantics for method calls 
  (in contrast to e.g. google protocol buffers) 
- and is not bloated (like e.g. Corba or others) 

What we were missing for example was a wireshark plugin for etch that can display 
the symbols from the .etch file and interpret tcp messages accordingly. We implemented
such a plugin, it works fine and could be part of official Apache Etch, too.

The long term plans for etch that are present on the website right now are nice, but at the

moment quite far away from what I read here in the mailing lists. This should be seen realisitic.

I think the project should focus on getting all the bindings ready (or focus on some of them
), 
as well as on finding a way to seriously continue supporting them. C# (besides JavaScript)
is the only 
binding that supports the xml transport at the moment. We also tried out the JavaScript binding

and had use cases, where a xml transport with a e.g. Java or C client/server on the other
side 
would have been useful. Those things should be addressed in my opinion. Naming Service, true
service 
orientation and the other stuff from the road map are nice, but rather big steps. 
Smaller steps are sometimes better.

Anyway, we really appreciate a discussion happening and we look forward to your answers,
Holger Grandy
Michael Fitzner


-----Original Message-----
From: Gav... [mailto:gavin@16degrees.com.au] 
Sent: Dienstag, 20. April 2010 16:16
To: etch-dev@incubator.apache.org
Subject: RE: FW: Etch C Binding - how to continue?



> -----Original Message-----
> From: Youngjin Park (youngjpa) [mailto:youngjpa@cisco.com]
> Sent: Wednesday, 21 April 2010 12:05 AM
> To: etch-dev@incubator.apache.org
> Subject: Re: FW: Etch C Binding - how to continue?
> 
> Hi,
> 
> I am sorry that I repled to you late. I was too much tied to the urgent
> projects recently and I also had some personal issue. So I am now on
> PTO.

Personal issues are understandable, and I'm sorry I dragged your name into
it, everyone does things when they get time. However with nearly a year and
nothing gone into subversion is not doing this project any good at all.

> 
> I said that I would start in a couple of weeks and I have started to
> look into codes. But, unfortunately not any major completion yet.

I'm worried about 'major completion' in this context. Committers should be
putting code into subversion regularly, a patch here and there, commit early
and often is the motto. Nothing needs to be 'major' or 'complete' , as long
as
it doesn't break trunk it can and should go in. Others can then see that
something is happening, work is being done, people are interested. they also
get to see early on what is in your head. Rather than wait for a huge code
dump to come in and have to wade through.

Take a look at svn.apache.org/viewvc , see how other projects are
committing, I
bet the average commit is 5 or 10 lines at most.

> 
> I will talk with Scott sometime in this week before I come back from
> PTO, and I will hear his advice and comments from Scott.

Ok, thanks for your reply.

Gav...

> 
> Thanks.
> 
> Youngjin
> 
> ----- Original Message -----
> From: Gav... <gavin@16degrees.com.au>
> To: etch-dev@incubator.apache.org <etch-dev@incubator.apache.org>
> Sent: Tue Apr 20 06:50:06 2010
> Subject: RE: FW: Etch C Binding - how to continue?
> 
> 
> 
> > -----Original Message-----
> > From: scott comer [mailto:wert1y@mac.com]
> > Sent: Tuesday, 20 April 2010 11:10 PM
> > To: Holger Grandy
> > Cc: youngjpa@cisco.com; Michael Fitzner; etch-
> dev@incubator.apache.org
> > Subject: Re: FW: Etch C Binding - how to continue?
> >
> > no reflection on you or etch or anything. just my own personal state,
> > which is wife is job searching and finishing school and i've got a
> > deadline in two weeks with major server features and i love etch and
> am
> > using it but have no issues really. it just works for me right now.
> >
> > we had a plan, last year, for adding such features as befits a
> service
> > oriented architecture: name service, configuration service, router,
> > etc.
> > you can read about those on the wiki. nobody responded to our ideas
> at
> > the time. i'd like to see c and c++ and python and ruby bindings, fix
> a
> > few bugs. i would like to contribute bosh / json binding which i have
> > cooking, and my json/ajax(?) binding as well.
> >
> > the wiki is in a not such a good state, and we could use some help
> > there
> > documenting what we do have and how to use it. there are other things
> > listed in the jira that need doing.
> 
> Holger and Michael have PUT things in Jira - with patches, been there
> since
> January, which I have pointed out many times.
> 
> >
> > i'd have more energy, i think, if there were folks actively
> interested
> > in helping and discussing where things should go.
> 
> The fact that Holger and Michael have put patches into the issue
> tracker
> surely
> means they are active and interested, as well as participate on the
> mailing
> list.
> 
> > it isn't really my
> > job
> > to say where etch should go in the absence of reasonable input from
> > others. cisco informed our direction before, and we had a real need
> for
> > the things we discussed. i might have a real need for them again. but
> i
> > don't right now. i guess i'm just a little tired of talking into an
> > empty room.
> 
> Yes and so am I, the lack of response to my queries on the private list
> is
> also tiresome; and worrying for the future of this project.
> 
> I have asked questions on some jiras and asked for feedback, got none.
> Youngjin
> assigned himself some issues in January, promised to do them in a week,
> yet
> here
> we are in April.
> 
> If the current developers are happy with the state of the project as it
> is,
> then
> they need to move aside and let others who actually want to work on it,
> do
> so.
> 
> With zero commits in nearly a year, I'm about ready to recommend this
> project be
> marked dormant and retired unless something starts to happen.
> 
> I'm sorry that the lack of replies to the private list forced this
> discussion into
> the public arena, but it needs to be done.
> 
> Gav...
> 
> >
> > you could start by saying what it is you are looking for, where do
> you
> > want to go? what's missing? what would be cool?
> >
> > scott out
> >
> > On 4/20/2010 5:13 AM, Holger Grandy wrote:
> > > Hi Scott,
> > > hi Youngjin,
> > >
> > > I hope you received our mail and that I should not conclude that no
> > answer is also an answer...
> > >
> > > What's up with Etch? I guess nobody of the current committers
> > currently has time left to actively
> > > develop Etch further. So is there any reason not to answer our
> mails?
> > >
> > > For us Etch is a very useable technology that fits our needs. We
> > actively use it and see good technical
> > > reasons for doing so. I know there are others that see it the same
> > way. What is your plan for the future of Etch?
> > > We will continue using it and develop for it. But of course the
> > question on the sustainability of such an
> > > approch arises. We want to prevent a true fork from the Apache
> > Software Foundation.
> > > But at the moment we are really missing arguments on whether to
> > further support etch as an incubator
> > > project when there is not even some feedback regarding new
> > contributions from the existing developers.
> > >
> > > What do you think?
> > >
> > > Kind regards,
> > > Holger Grandy
> > > Michael Fitzner
> > >
> > >
> > > -----Original Message-----
> > > From: Holger Grandy
> > > Sent: Dienstag, 6. April 2010 13:21
> > > To: 'wert1y@mac.com'; 'youngjpa@cisco.com'
> > > Cc: Michael Fitzner
> > > Subject: Etch C Binding - how to continue?
> > >
> > > Hi Scott,
> > > hi Youngjin,
> > >
> > > did you find some time to look into our C binding source code for
> > Etch?
> > >
> > > Today we prepared a new release of the C binding source, available
> at
> > http://github.com/bmwcarit/etch
> > >
> > > We have also been working on a wireshark plugin for etch, which is
> > capable of reading the idl's symbols
> > > and display etch calls on the wire. The C Compiler for etch has
> been
> > adopted to generate a suitable
> > > symbol list for wireshark. This is not yet finished, but I think we
> > could opensource this, too.
> > >
> > > How can we proceed with all this? We would really like to see the
> > Etch project grow. Is it possible
> > > to submit this source code also to the ASF? We would of course be
> > available as committers, if you
> > > want this and if you like the C Binding.
> > >
> > > Please give us feedback on what you think about it and make a
> > suggestion on how to proceed. We noticed
> > > that Etch in the ASF has become quiet in the last months... Let's
> > awake it again :)
> > >
> > > Thanks a lot for your answer,
> > >
> > > Kind Regards,
> > >
> > > Holger Grandy
> > > and
> > > Michael Fitzner
> > >
> > >
> 
> 




Mime
View raw message