Hello

OK to everything.

I understand you don't know if I like simplicity or not, and you can't trust anyone without deeper knowledge of him. The same
happends to me.

I agree with Roman its better to delay the discussion until version 1.0 are delivered. I'm doing now some package/architecture
analisys, and as soon as I finish it I'll will try to offer a complete solution and document it as a mention before.

Anyway, if you want the detailed description of the change I send in a previous mail the refactoring/relocation step by step.

Best Regards
Blas Rodriguez Somoza

----- Original Message -----
From: "David Jencks" <davidjencks@...>
To: <Firebird-Java@yahoogroups.com>
Sent: Wednesday, May 22, 2002 5:31 PM
Subject: Re: [Firebird-Java] thin jdbc-2 only (Re: Jdbc 2.0 Patches)


> 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/
> >
> >
> >
> >
> >
>
>
> 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/
>
>
>