Menu
▾
▴
proxool-developer
|
From: Bill H. <bi...@lo...> - 2004-03-23 20:28:04
|
Hi all, Just an update for everyone. Following Bertrand's recommendation, I've changed the ProxyFactory so that when we proxy a connection or a statement we also implement the same public interfaces as the original object. The upshot of this is that you can now do: Connection c = DriverManager.getConnection(url, properties); OracleConnection oc = (OracleConnection) c; This means we can probably deprecate the old ProxoolFacade.getDelegateConnection and getDelegateStatement methods. I say "probably" because the new proxy solution only works for interfaces. All well written drivers should be written to interfaces but if anyone is using a connection object that provides public methods that aren't declared in an interface then they won't be accessible. I'm tempted to live with that limitation. Remember, exposing the delegate connection is a weakness since it allows people to close the delegate instead of the proxy thereby not returning it to the pool. All this is uncommitted at the moment. Committing very soon. - Bill |
|
From:
<chr...@em...> - 2004-03-24 09:38:44
|
Oh. I might have been a bit naive to the usability of this :( A quick check on interface based JDBC implementations: SQLServer: No Sybase: Yes postgreSQL: Yes MySQL: No DB2: No ...and then you have Oracle. Here the confusion is complete, with definitions changing from version to version from class to interface etc. In some versions interfaces from the "internal" package is used, in some versions not. We should certantly NOT deprecate DriverManager.getConnection and friends. I am very uncertain wether this stuff is going to add value or confusion. Please consider this again. By the way; your example below won't work with the Oracle driver we use (8.1.7.0.4). OracleConnection is a class there... CHR Bill Horsman wrote: >Hi all, > >Just an update for everyone. Following Bertrand's recommendation, I've >changed the ProxyFactory so that when we proxy a connection or a >statement we also implement the same public interfaces as the original >object. The upshot of this is that you can now do: > > Connection c = DriverManager.getConnection(url, properties); > OracleConnection oc = (OracleConnection) c; > >This means we can probably deprecate the old >ProxoolFacade.getDelegateConnection and getDelegateStatement methods. I >say "probably" because the new proxy solution only works for interfaces. >All well written drivers should be written to interfaces but if anyone >is using a connection object that provides public methods that aren't >declared in an interface then they won't be accessible. I'm tempted to >live with that limitation. > >Remember, exposing the delegate connection is a weakness since it allows >people to close the delegate instead of the proxy thereby not returning >it to the pool. > >All this is uncommitted at the moment. Committing very soon. > >- Bill > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Proxool-developer mailing list >Pro...@li... >https://lists.sourceforge.net/lists/listinfo/proxool-developer > > > |
|
From: Bill H. <bi...@lo...> - 2004-03-24 10:00:39
|
CHR, On Wed, 2004-03-24 at 09:44, Christian Nedreg=E5rd wrote: > A quick check on interface based JDBC implementations: > SQLServer: No > Sybase: Yes > postgreSQL: Yes > MySQL: No > DB2: No What does that mean? A "no" means that the driver doesn't implement any driver specific interfaces? > ...and then you have Oracle. Here the confusion is complete Sounds par for the course. > We should certantly NOT deprecate DriverManager.getConnection and > friends.=20 Eh? How can we deprecate a JDK method? I'm confused.=20 I did mention deprecating ProxoolFacade.getDelegateConnection() and getDelegateStatement(). From what you say below that is probably not a good idea. > I am very uncertain wether this stuff is going to add value or > confusion. Please consider this again It won't do any harm. If a public interface for the object is available it will be used. If it isn't then it behaves like it did before. > By the way; your example below won't work with the Oracle driver we > use (8.1.7.0.4).=20 > OracleConnection is a class there... Hmm. Well that's a shame. But just to be clear, it will "work" in as much as Proxool will behave itself. It just means that the cast won't work and you'll have to use ProxoolFacade.getDelegateConnection(). Which is probably what you meant. In summary: I think that exposing the public interfaces is still a good idea. It won't be as useful as I originally thought because not all drivers use public interfaces, but it's certainly a step forwards. - Bill |
|
From:
<chr...@em...> - 2004-03-24 12:25:09
|
Bill Horsman wrote: >CHR, > >On Wed, 2004-03-24 at 09:44, Christian Nedreg=E5rd wrote: > > =20 > >>A quick check on interface based JDBC implementations: >>SQLServer: No >>Sybase: Yes >>postgreSQL: Yes >>MySQL: No >>DB2: No >> =20 >> > >What does that mean? A "no" means that the driver doesn't implement any >driver specific interfaces? > > =20 > It means that the implementations of Connection, Statement etc. does not=20 implement any vendor spesific interfaces. >>...and then you have Oracle. Here the confusion is complete >> =20 >> > >Sounds par for the course. > > =20 > Eh? You've reached the borders of my understanding of English mate ;) >>We should certantly NOT deprecate DriverManager.getConnection and >>friends.=20 >> =20 >> > >Eh? How can we deprecate a JDK method? I'm confused.=20 > > > =20 > Sorry. I meant ProxoolFacade.getDelegateConnection(). >>I am very uncertain wether this stuff is going to add value or >>confusion. Please consider this again >> =20 >> > >It won't do any harm. If a public interface for the object is available >it will be used. If it isn't then it behaves like it did before. > > =20 > >>By the way; your example below won't work with the Oracle driver we >>use (8.1.7.0.4).=20 >>OracleConnection is a class there... >> =20 >> > >Hmm. Well that's a shame. But just to be clear, it will "work" in as >much as Proxool will behave itself. It just means that the cast won't >work and you'll have to use ProxoolFacade.getDelegateConnection(). Which >is probably what you meant. > =20 > It means that the cast might work when you are using one version of the=20 Oracle driver, and then break when you change driver version, wich will=20 be extremely confusing to the user. >In summary: I think that exposing the public interfaces is still a good >idea. It won't be as useful as I originally thought because not all >drivers use public interfaces, but it's certainly a step forwards. > > > =20 > It's flabby (something that might work with a particular driver version=20 from a few of the vendors). I don't like flabby, but I won't veto this=20 either. CHR > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick >_______________________________________________ >Proxool-developer mailing list >Pro...@li... >https://lists.sourceforge.net/lists/listinfo/proxool-developer > > =20 > |
|
From: Bill H. <bi...@lo...> - 2004-03-24 12:56:44
|
Hi, On Wed, 2004-03-24 at 12:31, Christian Nedreg=E5rd wrote: > > Sounds par for the course. > Eh? You've reached the borders of my understanding of English mate ;) It's a golfing reference :) It means "what you would expect". > It means that the cast might work when you are using one version of > the Oracle driver, and then break when you change driver version, wich > will be extremely confusing to the user. Is it true that later versions use interfaces and earlier versions don't? If so, then I think it is fine.=20 > It's flabby (something that might work with a particular driver > version from a few of the vendors). I don't like flabby, but I won't > veto this either. I prefer to think of the drivers as flabby :) I think they should write their APIs to interfaces. But it would require some FAQ entries. Like: Q - Why can't I cast the Connection to an OracleConnection? A - You need to upgrade to version 8.x.y or later. Or if we felt like being a bit more general: Q - Why can't I cast the Connection to an XyzConnection? A - Proxool's Connection only implements public interfaces provided by the driver. If XyzConnection isn't an interface then you can't cast it. - Bill |
|
From:
<chr...@em...> - 2004-03-24 14:35:59
|
>It's a golfing reference :) It means "what you would expect". > > > Oooh. Moving up the social hierachy of metaphores are we ;) >>It means that the cast might work when you are using one version of >>the Oracle driver, and then break when you change driver version, wich >>will be extremely confusing to the user. >> >> > >Is it true that later versions use interfaces and earlier versions >don't? If so, then I think it is fine. > > Probably. >>It's flabby (something that might work with a particular driver >>version from a few of the vendors). I don't like flabby, but I won't >>veto this either. >> >> > >I prefer to think of the drivers as flabby :) I think they should write >their APIs to interfaces. > > Aiight! I'm convinced... But please do not focus on this as a *grand* new feature when we release. Its a good idea I agree, but vendor flabbiness will lead to a lot of dissapointed and confused users. Agreed? CHR |
|
From: Bill H. <bi...@lo...> - 2004-03-24 14:39:41
|
CHR, On Wed, 2004-03-24 at 14:41, Christian Nedreg=E5rd wrote: > Oooh. Moving up the social hierachy of metaphores are we ;) I'm moving up yes. But I'm not so proud that I won't still speak to you. I'll still remember you when I'm famous :) > I'm convinced... But please do not focus on this as a *grand* new > feature when we release. Its a good idea I agree, but vendor > flabbiness will lead to a lot of dissapointed and confused users. > Agreed? Agreed. - Bill |
|
From: Bertrand R. <ber...@mo...> - 2004-03-24 15:05:36
|
> > Oooh. Moving up the social hierachy of metaphores are we ;) >=20 > I'm moving up yes. But I'm not so proud that I won't still=20 > speak to you. I'll still remember you when I'm famous :) >=20 Can't follow you anympore :( > > I'm convinced... But please do not focus on this as a *grand* new=20 > > feature when we release. Its a good idea I agree, but vendor=20 > > flabbiness will lead to a lot of dissapointed and confused users.=20 > > Agreed? >=20 > Agreed. >=20 You know what ? The pluggable ConnectionBuilder I was talking about last time may = provide a solution. If required, people could build their own connection builder. This = builder would return an adapter around the vendor supplied connection. If this adapter implements an interface, then it would become = available/implemented by Bill's disposable wrapper... This way, the recommended approach to get access to functionalities = exposed by the *real* connection would be: - if your real connection implements an Interface, then just cast the proxool-connection to that interface; - if not - shame on your vendor! - build your own ConnectionBuilder... The ...getConnection() returning the *real* connection could then be = dropped (safer!) ? -bertrand |
|
From: Bill H. <bi...@lo...> - 2004-03-24 16:24:43
|
Bertrand, On Wed, 2004-03-24 at 15:05, Bertrand Renuart wrote: > The pluggable ConnectionBuilder I was talking about last time may provide a > solution. > If required, people could build their own connection builder. This builder > would return an adapter around the vendor supplied connection. I see that might be possible. But writing an adapter is not a trivial task. And they would have to maintain it across JDK versions. I suppose they could provide just the interface and we could include that in out proxy class... No adapter needed. Just their own interface that matches the API of the driver's Connection object. I wonder whether that would work. - Bill |
|
From: Bertrand R. <ber...@mo...> - 2004-03-24 21:12:40
|
> > The pluggable ConnectionBuilder I was talking about last time may=20 > > provide a solution. If required, people could build their own=20 > > connection builder. This builder would return an adapter around the=20 > > vendor supplied connection. >=20 > I see that might be possible. But writing an adapter is not a=20 > trivial task. And they would have to maintain it across JDK versions. >=20 As you say *they* would have to maintain it... Not the proxool team! Anyway, this workaround would be for drivers not implementing interfaces = and people wanting to access their special features... > I suppose they could provide just the interface and we could=20 > include that in out proxy class... No adapter needed. Just=20 > their own interface that matches the API of the driver's=20 > Connection object. I wonder whether that would work. >=20 You point to another (easier) solution: the ability for people to = *inject* interfaces in our proxy class. They could define an interface containing the signature of the methods = they want from the vendor jdbc connection (rs and st as well); then register = this extra interface with proxool. When building the proxy, you would add these extra interfaces to the proxy... |
|
From: Bill H. <bi...@lo...> - 2004-03-24 21:20:23
|
Bertrand,
On Wed, 2004-03-24 at 21:12, Bertrand Renuart wrote:
> You point to another (easier) solution: the ability for people to *inject*
> interfaces in our proxy class.
>
> They could define an interface containing the signature of the methods they
> want from the vendor jdbc connection (rs and st as well); then register this
> extra interface with proxool.
1.
<proxool>
<alias>my-oracle-pool</alias>
<driver-url>jdbc:oracle...</driver-url>
<driver-class>oracle.jdbc.OracleDriver</driver-class>
<connection-interface>
com.outside.jdbc.StrangeConnectionIF
</connection-interface>
</proxool>
2.
public interface StrangeConnectionIF {
public void foo();
}
3.
Connection c = DriverManager.getConnection(url, properties);
StrangeConnectionIF sc = (StrangeConnectionIF) c;
sc.foo();
Like that?
- Bill
|
|
From: Bertrand R. <ber...@mo...> - 2004-03-24 21:33:14
|
> Bertrand,
>=20
> On Wed, 2004-03-24 at 21:12, Bertrand Renuart wrote:
>=20
> > You point to another (easier) solution: the ability for people to=20
> > *inject* interfaces in our proxy class.
> >=20
> > They could define an interface containing the signature of=20
> the methods=20
> > they want from the vendor jdbc connection (rs and st as well); then=20
> > register this extra interface with proxool.
>=20
> 1.
> <proxool>
> <alias>my-oracle-pool</alias>
> <driver-url>jdbc:oracle...</driver-url>
> <driver-class>oracle.jdbc.OracleDriver</driver-class>
> <connection-interface>
> com.outside.jdbc.StrangeConnectionIF
> </connection-interface>
> </proxool>
>=20
> 2.
> public interface StrangeConnectionIF {
> public void foo();
> }
>=20
> 3.
> Connection c =3D DriverManager.getConnection(url, properties);
> StrangeConnectionIF sc =3D (StrangeConnectionIF) c;
> sc.foo();
>=20
> Like that?
>=20
Yes, something like that. Would be cool, no?
Except, to be easy to use, the StrangeConnectionIF should somehow extend
java.sql.Connection - otherwise the guy will have to recast all the time =
-
but this is up to him to sort it out ;-)
BUT, you then have to be carefull when building your proxy because you =
may
have several interfaces to implement that extend the same parent
(java.sql.Connection) - not sure it is a problem...
And we should also include the following extensions:
<resultset-interface>
com.outside.jdbc.StrangeResultSetIF
</resultset-interface>
<statement-interface>
com.outside.jdbc.StrangeStatementIF
</statement-interface>
In any case, if this is not enough - remains the ConnectionBuilder =
extension
point (which is working btw)...
Proxool becomes more and more open ;)
Remark:
I'm +100K in favor of the two solutions described in this thread rather =
than
exposing the *real* connection to the user...
|
|
From: Bill H. <bi...@lo...> - 2004-03-24 21:49:22
|
On Wed, 2004-03-24 at 21:33, Bertrand Renuart wrote: > Except, to be easy to use, the StrangeConnectionIF should somehow extend > java.sql.Connection - otherwise the guy will have to recast all the time - > but this is up to him to sort it out ;-) Good point for documentation though. > BUT, you then have to be carefull when building your proxy because you may > have several interfaces to implement that extend the same parent > (java.sql.Connection) - not sure it is a problem... It isn't. > And we should also include the following extensions: > > <resultset-interface> > com.outside.jdbc.StrangeResultSetIF > </resultset-interface> Not needed. We don't proxy the ResultSet. At least, not yet. > <statement-interface> > com.outside.jdbc.StrangeStatementIF > </statement-interface> And PreparedStatement and CallableStatement. - Bill |
|
From:
<chr...@em...> - 2004-03-24 21:40:57
|
Phrooh!
Why do you consider tying your code to a self-produced interface tied
to the currently exposed methods of a vendor spesific class to be more
robust and maintainable than tying your code to a ProxoolFacade method?
Using Proxool facade saves you both the writing/maintaining of the
interface and the extra configration.
CHR
Bill Horsman wrote:
>Bertrand,
>
>On Wed, 2004-03-24 at 21:12, Bertrand Renuart wrote:
>
>
>
>>You point to another (easier) solution: the ability for people to *inject*
>>interfaces in our proxy class.
>>
>>They could define an interface containing the signature of the methods they
>>want from the vendor jdbc connection (rs and st as well); then register this
>>extra interface with proxool.
>>
>>
>
>1.
> <proxool>
> <alias>my-oracle-pool</alias>
> <driver-url>jdbc:oracle...</driver-url>
> <driver-class>oracle.jdbc.OracleDriver</driver-class>
> <connection-interface>
> com.outside.jdbc.StrangeConnectionIF
> </connection-interface>
> </proxool>
>
>2.
> public interface StrangeConnectionIF {
> public void foo();
> }
>
>3.
> Connection c = DriverManager.getConnection(url, properties);
> StrangeConnectionIF sc = (StrangeConnectionIF) c;
> sc.foo();
>
>Like that?
>
>- Bill
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Proxool-developer mailing list
>Pro...@li...
>https://lists.sourceforge.net/lists/listinfo/proxool-developer
>
>
>
|
|
From: Bill H. <bi...@lo...> - 2004-03-24 21:49:19
|
On Wed, 2004-03-24 at 21:41, Christian Nedreg=E5rd wrote: > Phrooh! ! > Why do you consider tying your code to a self-produced interface tied > to the currently exposed methods of a vendor spesific class to be more > robust and maintainable than tying your code to a ProxoolFacade > method? That's not the point. By exposing the real connection people can really easily call close() or prepareStatement() directly. (In fact, they are quite likely to build Statements directly). Calling close() directly loses the connection forever. Building a Statement that Proxool doesn't know about stops Proxool resetting the connection correctly when it is returned to the pool.=20 > Using Proxool facade saves you both the writing/maintaining of the > interface and the extra configration. I agree with you there. I'm cautious about the extra work involved.=20 And I agree that tying your code to a self-written interface rather than the Oracle (or whatever) class is no better. - Bill |
|
From: Bertrand R. <ber...@mo...> - 2004-03-24 22:09:30
|
> That's not the point. By exposing the real connection people=20
> can really easily call close() or prepareStatement()=20
> directly. (In fact, they are quite likely to build Statements=20
> directly). Calling close() directly loses the connection=20
> forever. Building a Statement that Proxool doesn't know about=20
> stops Proxool resetting the connection correctly when it is=20
> returned to the pool.=20
>=20
That's it - and I think everybody will agree.
> > Using Proxool facade saves you both the writing/maintaining of the=20
> > interface and the extra configration.
>=20
> I agree with you there. I'm cautious about the extra work involved.=20
>=20
> And I agree that tying your code to a self-written interface=20
> rather than the Oracle (or whatever) class is no better.
>=20
I cannot agree with either statements ;)
What are we trying to solve?
We want to give people a way to access vendor specific extensions =
without
giving them the *real* connection.
As we said, this is not a problem if the vendor driver is coded against =
an
interface.
The problem is when the *real* connection is a concrete class, without
interface.
Conclusion: the user wants to use the extra features - so he becomes =
tied to
this particular driver. And he will have to maintain his code as the =
vendor
changes his interface.
______________
First Solution
The *real* connection is available via the ProxoolFacade. The usage =
scenario
becomes:
1/ Connection c =3D DriverManager.getConnection();
2/ com.vendor.VendorConnection vc =3D (com.vendor.VendorConnection)
ProxoolFacade.getRealConnection(c);
3/ call vc.vendorSpecificMethod();
-> you explcitlity depends on Proxool
-> you explicitly introduce the Vendor class everywhere in your code
(casting)
-> you get the *real* connection
_______________
Second Solution
1/ Define your own interface that mimics the VendorConnection (entirely =
or a
subset):
public interface VendorConnectionIF extends java.sql.Connection {
void vendorSpecificMethod();
}
(no need to define those you will not use)
2/ Inject this method in Proxool configuration
<proxool>
<alias>my-oracle-pool</alias>
<driver-url>jdbc:oracle...</driver-url>
<driver-class>oracle.jdbc.OracleDriver</driver-class>
<connection-interface>
yourpackage.VendorConnection
</connection-interface>
</proxool>
3/ Then use it
1/ yourpackage.VendorConnection c =3D
(yourpackage.VendorConnection)DriverManager.getConnection();
2/ call vc.vendorSpecificMethod();
-> you don't explicitly depend on Proxool (except in your configuration)
-> you are casting to an interface of your own (your own package - does =
it
matter ?)
-> you don't get the real connection
You still have to maintain your VendorConnectionIF interface in synch =
with
the signature of the Vendor driver - same overhead as solution 1.
___________
Conclusion:
I don't see any particular overhead for the user - same problem for both
solutions.
The user doesn't have access to the *real* connection.
For Proxool, the overhead is only to maintain the configuration code, =
the
injection of the user-supplied interface in the proxy is already part of =
the
creation of the dispoable wrapper...
-bertrand
|
|
From:
<chr...@em...> - 2004-03-24 22:10:56
|
I hate to be the devils advocate here... but maybe we can find a more simple and generic way of doing this? How about evaluating a full blown AOP approach instead? That is: We do not use proxies anomore, but simply intercept the methods we need to handle specially. This will prevent us from using the disposable wrapper though (i think)... CHR Bill Horsman wrote: >On Wed, 2004-03-24 at 21:41, Christian Nedregård wrote: > > > >>Phrooh! >> >> > >! > > > >>Why do you consider tying your code to a self-produced interface tied >>to the currently exposed methods of a vendor spesific class to be more >>robust and maintainable than tying your code to a ProxoolFacade >>method? >> >> > >That's not the point. By exposing the real connection people can really >easily call close() or prepareStatement() directly. (In fact, they are >quite likely to build Statements directly). Calling close() directly >loses the connection forever. Building a Statement that Proxool doesn't >know about stops Proxool resetting the connection correctly when it is >returned to the pool. > > > >>Using Proxool facade saves you both the writing/maintaining of the >>interface and the extra configration. >> >> > >I agree with you there. I'm cautious about the extra work involved. > >And I agree that tying your code to a self-written interface rather than >the Oracle (or whatever) class is no better. > >- Bill > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click >_______________________________________________ >Proxool-developer mailing list >Pro...@li... >https://lists.sourceforge.net/lists/listinfo/proxool-developer > > > |
|
From: Bill H. <bi...@lo...> - 2004-03-24 22:28:27
|
On Wed, 2004-03-24 at 22:11, Christian Nedreg=E5rd wrote: > I hate to be the devils advocate here...=20 But a useful role :) > but maybe we can find a more simple and generic way of doing this? I'm with you so far... > How about evaluating a full blown AOP approach instead?=20 That seems like a big step. Would it be possible to have an AOP solution alongside the proxy one? I think it should be a configurable option (if that is possible) > simply intercept the methods we need to handle specially.=20 I like the "simply" ;-) > This will prevent us from using the disposable wrapper though (i > think)... I would hope not. Or at least, an AOP solution should be as robust as disposable wrappers. By all means, lets explore an AOP solution. But it has to be as well as these other solutions we are providing. If Proxool-AOP becomes a good solution then it might replace the current system but I don't see that happening anytime soon. - Bill |
|
From:
<chr...@em...> - 2004-03-24 22:34:20
|
Well argued Bertrand :) And yes Bill, a fully blown AOP soution is a bit on the horizon. I'm sold methinks. Implement it and lets see how it works out. CHR Bill Horsman wrote: >On Wed, 2004-03-24 at 22:11, Christian Nedregård wrote: > > > >>I hate to be the devils advocate here... >> >> > >But a useful role :) > > > >>but maybe we can find a more simple and generic way of doing this? >> >> > >I'm with you so far... > > > >>How about evaluating a full blown AOP approach instead? >> >> > >That seems like a big step. Would it be possible to have an AOP solution >alongside the proxy one? I think it should be a configurable option (if >that is possible) > > > >>simply intercept the methods we need to handle specially. >> >> > >I like the "simply" ;-) > > > >>This will prevent us from using the disposable wrapper though (i >>think)... >> >> > >I would hope not. Or at least, an AOP solution should be as robust as >disposable wrappers. > >By all means, lets explore an AOP solution. But it has to be as well as >these other solutions we are providing. If Proxool-AOP becomes a good >solution then it might replace the current system but I don't see that >happening anytime soon. > >- Bill > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click >_______________________________________________ >Proxool-developer mailing list >Pro...@li... >https://lists.sourceforge.net/lists/listinfo/proxool-developer > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X