1. I agree this discussion has been waaaaay too long.

2. I definitely want better code quality, modularity, simplicity, etc etc.

3. If you have a better design I definitely want to see it. I suspect it
will be a wonderful improvement, but I don't know much about your coding
yet. Some people like extra layers of packages and interfaces and
abstraction for no apparent need, and the result is just more complex, not
easier to change. So I hope you will understand why I want to see exactly
what you are proposing before I say I agree with it.

4. I think you are right that in its current state the driver may encourage
people to blame its lack of complete jdbc support on jca, whereas they are
IMO completely unrelated.

5. I would prefer if the missing jdbc features could be added into the
driver while keeping the "jca center" and having only one driver. I worry
that if we make a "jdbc non xa" version and a "jca/xa version" we will get
too much confusion and start breaking things. I also think that in the
future the jdbc spec will directly include jca support for the "xa"/pooling
level.

Anyway, I really appreciate the time you have put into this already and
would like very much to see the details of the refactoring you are
proposing.

Thanks
david jencks

On 2002.05.22 11:01:10 -0400 Blas Rodriguez Somoza wrote:
> 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
>
> ----- 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/
> >
> >
> >
>
>
>
> 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/
>
>
>
>
>