RE: Making Daffodil Replicator an Open Source : Suggestion

2004-08-09 Thread Ashish Srivastava
Hi Noel,
>"Replicator integrates impeccably with all .. JDBC drivers"
 
Daffodil Replicator is a tool which works on databases to create
publication, subscription and merging the replicated data. 
 
To interact with databases Daffodil Replicator uses JDBC driver
interface and it also assumes that base database supports following:
 
* All basic data types
* Primary key support
* Triggers with:
* Provision of getting old and new values
* Row level triggers or any alternate way to achieve row level
feature   (as given in SQL-Server)
* Auto increment field support or sequence support
 
Daffodil Replicator is compatible to SQL-Server, Oracle and Daffodil DB.
Providing support with additional database a very small task, we just
only need to override the methods of one generic class which maps the
datatypes and SQL syntax. We are very interested in making Daffodil
Replicator compatible to Axiom and Derby databases.
 
The developer community has shown great interest in this product which
we are able to gauge from the high ratings given by well know software
index web sites like www.jars.com   , Zaurus
  Software Index etc.
 
You can download the current version of Daffodil Replicator from
http://www.daffodildb.com:8080/eval/filldetails.jsp 
 
Regards,
Ashish Srivastava
www.daffodildb.com  
 
 
 
 
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: Monday, August 09, 2004 4:33 AM
To: [EMAIL PROTECTED]
Cc: Ashish Srivastava
Subject: RE: Making Daffodil Replicator an Open Source : Suggestion
 
Ashish Srivastava wrote:
 
> We are planning to make our Daffodil Replicator an open source
project.
 
I have read the information at
http://www.daffodildb.com/dbreplicator.php ,
but it is unclear from "Replicator integrates impeccably with all
Daffodil
database products as well as with selected third-party databases that
provide JDBC drivers" to what extent Daffodil Replicator would work with
other databases.  If you are interested in contributing to replication
that
would work with Axion and Derby, please let us know.
 
The key issue, however, is community interest.  We would want to see
interest from within the ASF, or an existing community outside the ASF.
 
  --- Noel
 
 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Incubation of iBATIS Data Mapper

2004-08-09 Thread Ted Husted
On Mon, 09 Aug 2004 00:15:22 -0400, Noel J. Bergman wrote:
> And you might want to talk with our DB project and see what interest also comes from 
>there.

It's true that we are all database/data persistence technologies, but, in my 
experience, there is much more to an Apache product than technology. My own concern as 
to db.apache.org would be scope.

* PMC Scope

We have six members of Team iBATIS, working on either the Java or .NET version, or 
both. Our initial expectation would be that all six would become the iBATIS PMC. As it 
stands, there are currently five members of the DB PMC overseeing four products, with 
over thirty committers. So, we would either have to skew the PMC:Committer ratio or 
amend our expectations. :)

* Product scope

We have two iBATIS.NET implementations now, Java and .NET, and some of us considering 
a PHP implementation as well. We also plan to found a specification subproject to 
define the iBATIS baseline for each implementation. With three subprojects, and a 
possible fourth, it seems that the iBATIS scope is broad enough to support a top-level 
project.

* Community scope

The iBATIS Java community does have a lot of crossover with the Jakarta community. The 
implementation uses Jakarta products, and many iBATIS developers use Jakarta products 
in their applications too. But, I do not sense a lot of crossover with the 
db.apache.org community. As it stands, we probably have more crossover with the 
Hibernate community. Many of us have used both Hibernate and iBATIS for different 
products at the same time. Though, OJB and Hibernate have much in common, so if we  
were more closely aligned, we could see more crossover between those Java communities. 
Of course, aside from Java, iBATIS also has a .NET community, and may develop a PHP 
community as well.

Given these concerns, we thought it might be best to start the discussion here, and 
get some feedback from the Incubator community, before making a proposal.

Of course, at the end of the day, I believe we care more about being a member of House 
Apache than in which room we hang our hat :)

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Incubation of iBATIS Data Mapper

2004-08-09 Thread Brian McCallister
+1 for this incubation, either joining db or as its own TLP wearing my 
DB PMC hat =)

On Aug 9, 2004, at 9:31 AM, Ted Husted wrote:
It's true that we are all database/data persistence technologies, but, 
in my experience, there is much more to an Apache product than 
technology. My own concern as to db.apache.org would be scope.

* PMC Scope

There are actually more PMC members than that, the last several added 
from OJB aren't on the website list (I am one of those unlisted people, 
oops!), I realized over the weekend. Will fix it as soon as I get the 
site looking right under Maven 1.0.

iBATIS seems to fit well into DB, but if they don't want that for 
personal reasons as a project, their call =) In terms of skewing the 
PMC -- skew away if need be, I am a firm believer in the "all active 
committers should be PMC members" goal =)

* Product scope

This, to me, is a good argument for TLP status. There has been much 
concern over Jakarta being HUGE and hard to oversee. For the record, I 
think that concern over size is less important than capturing the idea 
crossover that has happened in Jakarta, though. The growth of useful 
tools there has been huge, and I am firm believer it is to a large 
degree the close proximity of projects which fostered this (virtual 
PARC type atmosphere).

* Community scope

All of the current DB projects (other than those in incubator) started 
in Jakarta (go momma Jakarta!) or spent some time there. Crossover in 
terms of projects being used by committers may not be there, but 
crossover in the problem domain is, I think. That is a stronger 
argument for me.

Given these concerns, we thought it might be best to start the 
discussion here, and get some feedback from the Incubator community, 
before making a proposal.

Of course, at the end of the day, I believe we care more about being a 
member of House Apache than in which room we hang our hat :)
I cannot speak for the whole DB PMC, but I am pretty confident that the 
project would be quite happy to provide a hat peg and help as needed =) 
I'd love to see iBATIS join the DB project, and this seems the natural 
home for it, but if they really want a TLP, I certainly won't stand in 
the way (and would still be +1).

-Brian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Incubation of iBATIS Data Mapper

2004-08-09 Thread Brian McCallister
+1 for this incubation, either joining db or as its own TLP wearing my 
DB PMC hat =)

On Aug 9, 2004, at 9:31 AM, Ted Husted wrote:
It's true that we are all database/data persistence technologies, but, 
in my experience, there is much more to an Apache product than 
technology. My own concern as to db.apache.org would be scope.

* PMC Scope

There are actually more PMC members than that, the last several added 
from OJB aren't on the website list (I am one of those unlisted people, 
oops!), I realized over the weekend. Will fix it as soon as I get the 
site looking right under Maven 1.0.

iBATIS seems to fit well into DB, but if they don't want that for 
personal reasons as a project, their call =) In terms of skewing the 
PMC -- skew away if need be, I am a firm believer in the "all active 
committers should be PMC members" goal =)

* Product scope

This, to me, is a good argument for TLP status. There has been much 
concern over Jakarta being HUGE and hard to oversee. For the record, I 
think that concern over size is less important than capturing the idea 
crossover that has happened in Jakarta, though. The growth of useful 
tools there has been huge, and I am firm believer it is to a large 
degree the close proximity of projects which fostered this (virtual 
PARC type atmosphere).

* Community scope

All of the current DB projects (other than those in incubator) started 
in Jakarta (go momma Jakarta!) or spent some time there. Crossover in 
terms of projects being used by committers may not be there, but 
crossover in the problem domain is, I think. That is a stronger 
argument for me.

Given these concerns, we thought it might be best to start the 
discussion here, and get some feedback from the Incubator community, 
before making a proposal.

Of course, at the end of the day, I believe we care more about being a 
member of House Apache than in which room we hang our hat :)
I cannot speak for the whole DB PMC, but I am pretty confident that the 
project would be quite happy to provide a hat peg and help as needed =) 
I'd love to see iBATIS join the DB project, and this seems the natural 
home for it, but if they really want a TLP, I certainly won't stand in 
the way (and would still be +1).

-Brian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


[OT] Re: Incubation of iBATIS Data Mapper

2004-08-09 Thread Brian McCallister
Sorry for the double post, guess moderator let posting from my unsubbed 
account through!

-Brian
On Aug 9, 2004, at 10:10 AM, Brian McCallister wrote:
+1 for this incubation, either joining db or as its own TLP wearing my 
DB PMC hat =)

On Aug 9, 2004, at 9:31 AM, Ted Husted wrote:
It's true that we are all database/data persistence technologies, 
but, in my experience, there is much more to an Apache product than 
technology. My own concern as to db.apache.org would be scope.

* PMC Scope

There are actually more PMC members than that, the last several added 
from OJB aren't on the website list (I am one of those unlisted 
people, oops!), I realized over the weekend. Will fix it as soon as I 
get the site looking right under Maven 1.0.

iBATIS seems to fit well into DB, but if they don't want that for 
personal reasons as a project, their call =) In terms of skewing the 
PMC -- skew away if need be, I am a firm believer in the "all active 
committers should be PMC members" goal =)

* Product scope

This, to me, is a good argument for TLP status. There has been much 
concern over Jakarta being HUGE and hard to oversee. For the record, I 
think that concern over size is less important than capturing the idea 
crossover that has happened in Jakarta, though. The growth of useful 
tools there has been huge, and I am firm believer it is to a large 
degree the close proximity of projects which fostered this (virtual 
PARC type atmosphere).

* Community scope

All of the current DB projects (other than those in incubator) started 
in Jakarta (go momma Jakarta!) or spent some time there. Crossover in 
terms of projects being used by committers may not be there, but 
crossover in the problem domain is, I think. That is a stronger 
argument for me.

Given these concerns, we thought it might be best to start the 
discussion here, and get some feedback from the Incubator community, 
before making a proposal.

Of course, at the end of the day, I believe we care more about being 
a member of House Apache than in which room we hang our hat :)
I cannot speak for the whole DB PMC, but I am pretty confident that 
the project would be quite happy to provide a hat peg and help as 
needed =) I'd love to see iBATIS join the DB project, and this seems 
the natural home for it, but if they really want a TLP, I certainly 
won't stand in the way (and would still be +1).

-Brian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


[ftpserver] Mailing Lists

2004-08-09 Thread David H. DeWolf
The FtpServer site mentions that it's mailing lists have not yet been
created and that this list should be used for the time being.  Is there a
reason the lists are not created or are we simply waiting for someone to
take the initiative to request the setup from infrastructure?  Especially
now that an email request has gone out to several communities (geronimo and
avalon) requesting help, I'd think that ftpserver specific lists would help
people get involved and encourage more conversation.

On that note, I hope to help out by starting the requested mavenisation.  I
noticed that forest is currently being used for site generation.  Is the
desire of the ftpserver community to continue to use forest for site
generation or would you like that mavenised as well?


David




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Incubation of iBATIS Data Mapper

2004-08-09 Thread Ted Husted
On Mon, 09 Aug 2004 10:09:31 -0400, Brian McCallister wrote:
>
> I cannot speak for the whole DB PMC, but I am pretty confident that
> the project would be quite happy to provide a hat peg and help as
> needed =) I'd love to see iBATIS join the DB project, and this
> seems the natural home for it, but if they really want a TLP, I
> certainly won't stand in the way (and would still be +1).

I don't believe anyone has a strong inclination one way or the other. And if it had 
just been a matter of iBATIS for Java, I'd agree it would be no-brainer.

The key question would be whether members of the DB PMC will be comfortable overseeing 
code for products they don't use on platforms they don't use. :)

But if adding six members to the DB PMC is not an issue, and overseeing a DB product 
with non-Java implementations is not an issue, then I'm sure we'd be just as happy to 
apply through DB. The team is not jealous of other products. Depending on the 
application and the team, I know we all recognize that another product can be a better 
choice for someone.

-Ted.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: summary on Lenya vote?

2004-08-09 Thread Michael Wechner
Noel J. Bergman wrote:
It seems that everyone agrees to release Lenya from the incubator.
Can we do a summary on that, such we can use the summary for applying as
   

TLP.
Actually, I just went back through the vote thread, and from what I can see,
we have votes from Leo Simons, Steven Noels and myself.  I did look further
and found Nicola Ken's vote at
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
.org&msgId=1760664, so that's four.  I cannot find one from Stefano, and I'm
not particularly keen to ever infer someone's vote just because they started
the thread.  No one else seems to have voted.
ref:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
che.org&by=thread&from=822879
Please feel free to correct me if you find any other votes in the archives.
 

I guess you are right, whereas I assumed that no votes would
be counted as positive silent votes, because the thread was phrased
as a positive one. But I am not sure what the policy of the incubator is 
re voting.

As for applying for TLP status, I had indicated in a message to Steven Noels
earlier that, yes, the Lenya PPMC should prepare a proposal to the Board for
TLP status.  If no one objects to Lenya being promoted between now and the
Board meeting, you should be good to go.
 

ok
Thanks
Michi
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 


--
Michael Wechner
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com  http://cocoon.apache.org/lenya/
[EMAIL PROTECTED][EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Incubation of iBATIS Data Mapper

2004-08-09 Thread Rodney Waldhoff
On Mon, 9 Aug 2004, Ted Husted wrote:
if [...] overseeing a DB product with non-Java implementations is not an 
issue
There is nothing Java specific about the Apache DB charter, indeed the DB 
proposal specicially calls out a language-agnostic approach. 
 (Although all current 
Apache DB projects happen to be Java based.)

if adding six members to the DB PMC is not an issue
That the PMC is comprised of active committers on all sub-projects is the 
convention within the DB project.

- R.
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Incubation of iBATIS Data Mapper

2004-08-09 Thread Clinton Begin
>> I don't believe anyone has a strong inclination one way or the other.
I'll jump off the fence into a yard.  :-)
I'd prefer to see iBATIS as a TPL for the reasons Ted has laid out.  I 
don't think joining the DB project would benefit either team.

>> The key question would be whether members of the DB PMC will be
>> comfortable overseeing code for products they don't use on
>> platforms they don't use.
Another key question is whether the iBATIS team is comfortable 
overseeing the code for OJB and Torque.  I can only speak for myself.  I 
don't have much interest in being on the PMC for OJB or Torque.  iBATIS 
is a wide enough scope as is, and it will only grow faster.

iBATIS already has many subprojects and implementations.  This includes:
  - SQL Maps (to be called Data Mapper)
  - DAO (Data Access Objects)
  - JPetStore (example application)
** We have both Java and .Net implementations for each!
I have a lot of respect for the DB project, but I think it will simply 
become too big with iBATIS in there too.

Cheers,
Clinton
Ted Husted wrote:
On Mon, 09 Aug 2004 10:09:31 -0400, Brian McCallister wrote:
I cannot speak for the whole DB PMC, but I am pretty confident that
the project would be quite happy to provide a hat peg and help as
needed =) I'd love to see iBATIS join the DB project, and this
seems the natural home for it, but if they really want a TLP, I
certainly won't stand in the way (and would still be +1).

I don't believe anyone has a strong inclination one way or the other. And if it had just been a matter of iBATIS for Java, I'd agree it would be no-brainer. 

The key question would be whether members of the DB PMC will be comfortable overseeing code for products they don't use on platforms they don't use. :) 

But if adding six members to the DB PMC is not an issue, and overseeing a DB product with non-Java implementations is not an issue, then I'm sure we'd be just as happy to apply through DB. The team is not jealous of other products. Depending on the application and the team, I know we all recognize that another product can be a better choice for someone.  

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Incubation of iBATIS Data Mapper

2004-08-09 Thread Brandon Goodin
Greetings,

I would also have to agree that I feel more comfortable being a TLP rather
than part of the DB. I don't want to sound arrogant or presumptuous; I
simply think it would be organizationally cleaner. For example, we are
looking to add IBatis Productivity Tools to our repertoire of products. The
PTs look to provide services that span across the DAO and Data Mapper
products as well as into some areas of DAO generation and bean generation. I
see IBatis needing a garden to blossom in. Apache is fertile ground for the
planting and being an Apache TLP would give it that much more room to grow
adding to the continuing reputation of successful Apache products. I hope
that we can obtain the position of TLP in order to assure the continued
growth and success of IBatis and optimally serve the user base that we bring
along with us.

Thanks for your time,
Brandon Goodin

> -Original Message-
> From: Clinton Begin [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 09, 2004 5:15 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Incubation of iBATIS Data Mapper
> 
> 
>  >> I don't believe anyone has a strong inclination one way or the other.
> 
> I'll jump off the fence into a yard.  :-)
> 
> I'd prefer to see iBATIS as a TPL for the reasons Ted has laid out.  I
> don't think joining the DB project would benefit either team.
> 
>  >> The key question would be whether members of the DB PMC will be
>  >> comfortable overseeing code for products they don't use on
>  >> platforms they don't use.
> 
> Another key question is whether the iBATIS team is comfortable
> overseeing the code for OJB and Torque.  I can only speak for myself.  I
> don't have much interest in being on the PMC for OJB or Torque.  iBATIS
> is a wide enough scope as is, and it will only grow faster.
> 
> iBATIS already has many subprojects and implementations.  This includes:
> 
>- SQL Maps (to be called Data Mapper)
>- DAO (Data Access Objects)
>- JPetStore (example application)
> 
> ** We have both Java and .Net implementations for each!
> 
> I have a lot of respect for the DB project, but I think it will simply
> become too big with iBATIS in there too.
> 
> Cheers,
> Clinton
> 
> 
> Ted Husted wrote:
> > On Mon, 09 Aug 2004 10:09:31 -0400, Brian McCallister wrote:
> >
> >> I cannot speak for the whole DB PMC, but I am pretty confident that
> >> the project would be quite happy to provide a hat peg and help as
> >> needed =) I'd love to see iBATIS join the DB project, and this
> >> seems the natural home for it, but if they really want a TLP, I
> >> certainly won't stand in the way (and would still be +1).
> >
> >
> > I don't believe anyone has a strong inclination one way or the other.
> And if it had just been a matter of iBATIS for Java, I'd agree it would be
> no-brainer.
> >
> > The key question would be whether members of the DB PMC will be
> comfortable overseeing code for products they don't use on platforms they
> don't use. :)
> >
> > But if adding six members to the DB PMC is not an issue, and overseeing
> a DB product with non-Java implementations is not an issue, then I'm sure
> we'd be just as happy to apply through DB. The team is not jealous of
> other products. Depending on the application and the team, I know we all
> recognize that another product can be a better choice for someone.
> >
> > -Ted.
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [ftpserver] Mailing Lists

2004-08-09 Thread David H. DeWolf
My appologies, while the site says this general list is the place for
ftpserver discussions, I've since discovered that [EMAIL PROTECTED] appears
to be the correct location for the time being.

David

> -Original Message-
> From: David H. DeWolf [mailto:[EMAIL PROTECTED] 
> Sent: Monday, August 09, 2004 3:54 PM
> To: [EMAIL PROTECTED]
> Subject: [ftpserver] Mailing Lists
> 
> 
> The FtpServer site mentions that it's mailing lists have not 
> yet been created and that this list should be used for the 
> time being.  Is there a reason the lists are not created or 
> are we simply waiting for someone to take the initiative to 
> request the setup from infrastructure?  Especially now that 
> an email request has gone out to several communities (geronimo and
> avalon) requesting help, I'd think that ftpserver specific 
> lists would help people get involved and encourage more conversation.
> 
> On that note, I hope to help out by starting the requested 
> mavenisation.  I noticed that forest is currently being used 
> for site generation.  Is the desire of the ftpserver 
> community to continue to use forest for site generation or 
> would you like that mavenised as well?
> 
> 
> David
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: summary on Lenya vote?

2004-08-09 Thread Noel J. Bergman
> I assumed that no votes would be counted as positive silent votes

Nope.  There is a notion of "Lazy Consenus", but silence is not a vote.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]