| Subject | Re: [Firebird-Java] thin jdbc-2 only (Re: Jdbc 2.0 Patches) |
|---|---|
| Author | Blas Rodriguez Somoza |
| Post date | 2002-05-22T15:01:10Z |
Hello David et al
I think the focus of the proposal was misundertanded. Excuse me in advance if this mail is to hard but it seems I was too soft
until now, because no one understands clearly what I intend to do, perhaps excluding Roman.
First, I don't think take out something thas was implemented and supported by someone is a good idea. Perhaps someone want to
add a jdbc only alternate connection method, and if the driver has a modular architecture it will possible to do, but if jca is
implemented and work it has no sense to take it out.
My proposal only try to solve a serious problem in the driver, a problem of software quality. I don't want to critisize the way
the driver was developed, because every software project maintained for a long time, goes through situations where the code become
too mangled and must be refactored. It is not acceptable a software with so much dependencies between classes in different packages
that all the packages behaves as one. I hope everyone working with software know the value of modularization and components.
Software quality is not only a nice concept, is the difference between been productive or not, the difference between stable and
unstable software, in one word is the difference between good and bad software. Good software quality grants that a software piece
can be quickly understanded, and patched or modified safely and easy.
You mention that you want to refactor some part of the code because it makes the software cleaner, and I suppose this is enough
for you, but at the same time you need more explanations where I use the same reason .
Even Roman, who maintain the driver don't want to work on certain packages because he feels that is dangerous.
The real problem is that in an open source software like this Driver, if the people who develop and manage it don't go in the
direction the users need, then another solution will appear and the people than want to collaborate in the development will select
where they want to put it efforts. The solution that fulfil the community needs will grow and the other one die. That is open source
democracy.
If a database driver focus on JCA and forget the correct implementation of JDBC, will be a candidate to death in the open source
or in the commercial arena.
When I first test the firebird driver two weeks ago, I find that the driver fails and locks on too much tests to be used. During
a later test I decide to look inside and finally I find myself patching it. Now the driver has a very improved JDBC support, but it
is obvious that JDBC support is not considered a main focus on this driver until now and I don't know if it will be in the future.
If you overvalue JCA against JDBC, and the people now that, the logical consecuence is that everyone thinks that the problem for
the driver are JCA and because the driver supports JCA is why it supports so badly JDBC.
In this situation there are two ways to go.
The first one and more wise is try to refactor the code step by step and carefully to maintain everythink working during the
process, and add the features the people need whenever it is possible. The only purpose of this refactor is to make the code cleaner
and more understandable.
The second and less desirable one, is to lock in the actual situation and wait until someone begin a project to create a new
driver from the actual code, and probably dropping jca because you convince people that JCA was the problem.
I hope those lines makes clear why I propose the refactoring. In past e-mails I explain exactly what I propose to do. It seems
to me that what I propose is a really small change, too small to generate this mail activity.
As I explain sometime in the past in this mailing list, I'm not user of Interbase nor the Driver, I'm only collaborating because
I'm a software proffesional, I have deep knowledge of the JDBC api, and I need to fulfil my good actions quote for this year, but I
can do it also in other software project or in Greenpeace.
For me, because I'm not a user of the driver the problem is only a software engineering one and I don't have any passional
fellings about any api.
Regards.
Blas Rodriguez Somoza
I think the focus of the proposal was misundertanded. Excuse me in advance if this mail is to hard but it seems I was too soft
until now, because no one understands clearly what I intend to do, perhaps excluding Roman.
First, I don't think take out something thas was implemented and supported by someone is a good idea. Perhaps someone want to
add a jdbc only alternate connection method, and if the driver has a modular architecture it will possible to do, but if jca is
implemented and work it has no sense to take it out.
My proposal only try to solve a serious problem in the driver, a problem of software quality. I don't want to critisize the way
the driver was developed, because every software project maintained for a long time, goes through situations where the code become
too mangled and must be refactored. It is not acceptable a software with so much dependencies between classes in different packages
that all the packages behaves as one. I hope everyone working with software know the value of modularization and components.
Software quality is not only a nice concept, is the difference between been productive or not, the difference between stable and
unstable software, in one word is the difference between good and bad software. Good software quality grants that a software piece
can be quickly understanded, and patched or modified safely and easy.
You mention that you want to refactor some part of the code because it makes the software cleaner, and I suppose this is enough
for you, but at the same time you need more explanations where I use the same reason .
Even Roman, who maintain the driver don't want to work on certain packages because he feels that is dangerous.
The real problem is that in an open source software like this Driver, if the people who develop and manage it don't go in the
direction the users need, then another solution will appear and the people than want to collaborate in the development will select
where they want to put it efforts. The solution that fulfil the community needs will grow and the other one die. That is open source
democracy.
If a database driver focus on JCA and forget the correct implementation of JDBC, will be a candidate to death in the open source
or in the commercial arena.
When I first test the firebird driver two weeks ago, I find that the driver fails and locks on too much tests to be used. During
a later test I decide to look inside and finally I find myself patching it. Now the driver has a very improved JDBC support, but it
is obvious that JDBC support is not considered a main focus on this driver until now and I don't know if it will be in the future.
If you overvalue JCA against JDBC, and the people now that, the logical consecuence is that everyone thinks that the problem for
the driver are JCA and because the driver supports JCA is why it supports so badly JDBC.
In this situation there are two ways to go.
The first one and more wise is try to refactor the code step by step and carefully to maintain everythink working during the
process, and add the features the people need whenever it is possible. The only purpose of this refactor is to make the code cleaner
and more understandable.
The second and less desirable one, is to lock in the actual situation and wait until someone begin a project to create a new
driver from the actual code, and probably dropping jca because you convince people that JCA was the problem.
I hope those lines makes clear why I propose the refactoring. In past e-mails I explain exactly what I propose to do. It seems
to me that what I propose is a really small change, too small to generate this mail activity.
As I explain sometime in the past in this mailing list, I'm not user of Interbase nor the Driver, I'm only collaborating because
I'm a software proffesional, I have deep knowledge of the JDBC api, and I need to fulfil my good actions quote for this year, but I
can do it also in other software project or in Greenpeace.
For me, because I'm not a user of the driver the problem is only a software engineering one and I don't have any passional
fellings about any api.
Regards.
Blas Rodriguez Somoza
----- Original Message -----
From: "David Jencks" <davidjencks@...>
To: <Firebird-Java@yahoogroups.com>
Sent: Wednesday, May 22, 2002 4:56 AM
Subject: Re: [Firebird-Java] thin jdbc-2 only (Re: Jdbc 2.0 Patches)
> On 2002.05.21 18:18:53 -0400 rrokytskyy wrote:
> > Hi,
> >
> > > Well, since we want to potentially support many isolated programs
> > > running within a single JVM (using Jakarta Avalon Phoenix) on
> > > potentially very small devices (ie wearable computers in hospital
> > > setups) somewhere in the future, "slim" is still an issue. We're
> > > still evaluating whether even basic JDBC is an option in that
> > > case...
>
> I don't know anything about Phoenix, what does it do? You might look into
> writing your programs as mbeans running in a jmx container. JBoss is
> essentially a collection of mbeans providing various services that when
> combined result in a j2ee app server. One of our goals is to fit into tiny
> devices (we're hoping for a zaurus soon). You might find some of the
> services useful. Apparently jmx will be part of jdk 1.5.
> >
> > If we are talking about very small devices (small in meaning of
> > available RAM, not size), I would go for another architecture. Small
> > devices tend to cluster together into very big groups and access the
> > same resource at the same time, and I doubt that Firebird will
> > survive 1,000 simultaneous connections. If I were chief architect I
> > would go for something similar to Ninja project (Jini and e-speak are
> > competitors).
>
> I agree. I think direct jdbc access from a small or numerous device is
> highly inadvisable. I think communicating more specific structured
> information with an app server is considerably more plausible. Remember,
> JBoss is free, and the jca support was written with jboss in mind. (this is
> a different use of jboss than I mentioned above)
> >
> > > Nevertheless, KISS and other principles suggest the right
> > > granularity of components is important. From looking at package
> > > structure, it seemed to me there could be something important to
> > > gain in refactoring. Glad to have that cleared up.
> >
> > Refactoring is needed. I'm do like principle of agile/XP methods,
> > saying refactor whenever possible. But in my opinion, now only very
> > limited refactoring is possible.
>
> Won't someone please stop complaining and make a specific suggestion
> together with an argument about why it is an improvement! Whining is
> cheap, but I have yet to see any proposal that says "doing x will result in
> simplification y". I've only seen various parts of "I don't want to look
> at the code, but I do want to do z, but I won't tell you why". At least
> Blas has said something fairly specific about what he wants to do, and
> obviously has read all the code, but I still haven't figured out why he
> wants these changes.
>
> >
> > > One thing I can see needs a little work is some docs to explain
> > > interdependencies between JDBC and JCA drivers (and why this is not
> > > bad).
>
> Reading the jca spec I think is a reasonable place to start to understand
> this.
>
> > >
> > > thought one: how do I volunteer to add some of that? (where do the
> > > patches go?)
> >
> > Just raise your hand :). Then write some code/docs and post it either
> > here or directly to one of developers (currently David Jencks,
> > Alejandro Alberola Arias, me and Blas Rodriguez Somoza). We would be
> > happy to commit it into CVS. If you contribute regularly or will
> > contribute regularly, you will get CVS write access.
> >
> > > thought two: what kind of documentation system do you use/wish to
> > > use? (should everything be in the javadoc??)
> >
> > David Jencks created documentation guidelines, they are available
> > somewhere in Developer's corner/Firebird documentation/Tools section
> > on the Firebird's site (http://firebird.sourceforge.net/index.php?
> > op=devel&sub=doc&id=development#tools).
> >
> > In general, it is XML file, where all formatting is done using tags.
> > We will use XSL to transform it into printable format.
>
> I cribbed this from the jboss free docs project, and still like it,
> although the jboss docs seem to be moving to word format :-((((.
>
> It's docbook xml. I edit it using emacs + psgml, and the html and pdf is
> generated from the xml using various stylesheets and apache FOP (for pdf).
> Check out the manual module, it includes a build system and all the
> stylesheets, and one lone chapter.
>
> Another lighter possibility is to write up some more info for the website,
> directly in html.
>
> Anyway, all this interest is very encouraging, it seems that this work may
> be turning out to be useful and used.
>
> Thanks
> david jencks
>
> >
> > Best regards,
> > Roman Rokytskyy
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > Firebird-Java-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
> >
> >
> >
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>