Hi Roman,

To start with - sorry for the different email address - I cant yet
post to(but do recieve from) the normal one from home.

>Have you thought about the license for your code? May I suggest LGPL,

same

>as JayBird main code?

I think that would make most sense. As far as I'm aware LGPL still
allows intergration of the driver binaries into a commercial product ?

>Note, you must add a license to all your files before
>committing them.

Are you able to point me towards a suitable chunk of text ?

>This would be very good. But can you wait approx. one week (actually till
>the begining of the next week)? I would like to clean up JayBird's

code that

>will be released and fork a release branch. Then we can add your code

into

>the main source tree.

I was really only concerned with adding the native code at the moment
- this would be a start and would help me further develop the build
system. Adding this wont affect the java side of things. I am more
then happy to wait to get the java code intergrated. If anyone wants
to try it out in the mean time then the binaries are available for
download.

I would like to tidy the ngds package and strip out redundant code
that came from jgds package before adding this anyhow.

Once you've done your clean up I can get a fresh checkout and re-apply
my changes on the java side more cleanly and pass this too you for
your approval.

I dont know how much clean up you intend to do before forking the
release branch but at the end of this post is a summary of the
difficulties I had intergrating ngds which you might like to be aware of.

>What about:
>
>client-java/src/native - for native code.
>client-java/src/ngds - for your Java code if you want to commit now.

Looks good to me. As I said I'm only looking to add the native code at
the minute. If i put this under /src/native as it stands we would have:

/src/native/jaygds/source
/src/native/jaygds/source/external
/src/native/jaygds/builds/msvc6

I think the build's folder could go in here at least until the build
is properly intergrated/complete however this might be done. Perhaps I
would modify the msvc project for the time being to build into
'/output/native/jaygds/debug' and '/output/native/jaygds/release'.

If you are happy with this I will add this once I've got the liscense
text in place.

>if you like, you can check David Jencks' build.xml to build
>native part of InterClient. You may consider ant as a build

environment for

>your code too.

I've seen davids post regarding this. I will begin investigating the
options I am now aware of tonight - cross platform builds of the
native code is my current priority.


Considerations when intergrating ngds:

1) The following static methods on GDSFactory ...

public static Clumplet newClumplet(int type, String content)
public static Clumplet newClumplet(int type)
public static Clumplet newClumplet(int type, int c)
public static Clumplet newClumplet(int type, byte[] content)
public static Clumplet cloneClumplet(Clumplet c)

If these were moved to the GDS interface it would make it easier for
ngds to provide its own alternate implementation.

2) The following methods on isc_stmt_handle_imp

boolean getAllRowsFetched();
Object[] getRows();
int size();
void removeRows();

Are used by at least FBStatementFetcher causeing it to have to cast
to the jgds implementation. To deal with this in my modifications I
moved these up to the isc_stmt_handle interface and removed the casts
from FBStatementFetcher - the logic being that these had become part
of the gds interface package once they were used outside of jgds.

3) The static encodeXXX and decodeXXX on the XSQLVAR class. ngds
needed to provide alternative implementations of these to prevent it
having to re-order the bytes. Perhaps again the GDS interface may be
a good place for these - really I dont know.

These were the main difficulties that I found in providing an
alternate gds implementation. If these were dealt with then
intergrating ngds becomes trivial.

Also once these are dealt with getting some infomation through to
GDSFactory.newGDS to allow it to determin which gds implementation to
create might help in intergrating ngds.

Thanks
Ryan



-----Original Message-----
From: Roman Rokytskyy [mailto:rrokytskyy@...]
Sent: 06 March 2003 15:42
To: ryan.baldwin@...
Cc: Firebird-Java@yahoogroups.com
Subject: RE: Putting class 2 drv native code in CVS.


Hi Ryan,

> I feel it would be a good time to at put the native code for the type 2
> driver modifications in cvs. This would help me work on the code from
> different locations which I will need to do to make build's for other
> platforms - also to make it possible for others to contribute.

This would be very good. But can you wait approx. one week (actually till
the begining of the next week)? I would like to clean up JayBird's
code that
will be released and fork a release branch. Then we can add your code into
the main source tree.

If you still prefer to add it to the CVS now, then I think we have to
put it
in a directory parallel to the src/main/, because your java code
"conflicts"
with existing code in src/main/

> I was told your the person to ask about where to place this. I

assume that

> it should go in the client-java module. If so then where in

client-java is

> the question.

I think client-java would be the right place.

What about:

client-java/src/native - for native code.
client-java/src/ngds - for your Java code if you want to commit now.

> I hope to keep the native code self contained so that it can be built on
> entirely its own. I dont know if this is the best idea though.

Good. BTW, if you like, you can check David Jencks' build.xml to build
native part of InterClient. You may consider ant as a build
environment for
your code too.

> I was thinking that once the java side does get intergrated it might

be an

> idea to have binaries for this library in cvs so that the ant
> build file can package them with the distribution possible. These
> binaries would be kept in sync with the corrisponding cvs version of the
> java code.

Makes sense. Not every Java developer has C/C++ build environment, so
having
pre-compiled version of library would be a nice thing.

> Anyhow - for now getting it imported is the main thing so I would be
> gratefull for any help you can provide.

Have you thought about the license for your code? May I suggest LGPL, same
as JayBird main code? Note, you must add a license to all your files
before
committing them. If your license will be different from LGPL or MPL/IPL
(these are currently approved and in use), I think we will need to discuss
the license question in firebird-devel list.

Thanks!
Roman Rokytskyy

__________________________________________________ Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to
Email and Music Charts http://uk.my.yahoo.com