babeldoc-devel — Babeldoc developer list

Re: [Babeldoc-devel] Proposal for all the babeldoc developers - CALL FOR VOTE

[Hans B. <ben...@ch...>]

Dejan,

yes, it identifies the header comment by keys like "babeldoc:  universal
document processor", deletes it and replaces it with something else (or
the same).

cf. http://jalopy.sourceforge.net/header.html

Regards,
Hans

On Tue, 10 Jun 2003, Dejan Krsmanovic wrote:

> I agree with Hans. We need Jalopy anyway for code formatting. If it can add
> header to all sources than this is just one reason more to use it. Hans, can
> Jalopy remove old headers too?
>
> Dejan
>
>
> > In case you haven't started yet: It could also be a job for jalopy. And if
> > we touch and recommit all the files anyway, it would be a good moment to
> > add the jalopy target to the build files.
> >
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>

Re: [Babeldoc-devel] Proposal for all the babeldoc developers - CALL FOR VOTE

[Dejan K. <dej...@nb...>]

I agree with Hans. We need Jalopy anyway for code formatting. If it can add
header to all sources than this is just one reason more to use it. Hans, can
Jalopy remove old headers too?

Dejan


> In case you haven't started yet: It could also be a job for jalopy. And if
> we touch and recommit all the files anyway, it would be a good moment to
> add the jalopy target to the build files.
>

Re: [Babeldoc-devel] Proposal for all the babeldoc developers - CALL FOR VOTE

[Dejan K. <dej...@nb...>]

+1
I hope this licence change will attract more companies to use Babeldoc by
including it in their products. That could only help Babeldoc.

Dejan

----- Original Message -----
From: "Bruce McDonald" <br...@mc...>
To: <Bil...@Ac...>
Cc: <bab...@li...>
Sent: Tuesday, June 10, 2003 4:25 AM
Subject: Re: [Babeldoc-devel] Proposal for all the babeldoc developers -
CALL FOR VOTE


> I am leaning towards the Apache Public License - what do you think?  We
need a
> vote one this.  Every who dis/agrees that a license change is in order,
> please respond yes or no.  If yes, please provide your opinion on the new
> license (if you have an opinion).  Voting closes this friday.
>
> On Monday 09 June 2003 08:38 pm, Bill Harrelson wrote:
> > How about just including a blanket statement in one README file with a
date
> > that overrides all headers in any file dated prior to the included date?
> > Then just update the headers one-by-one as they are touched?
> >
> > Language like "This license supersedes and takes precedence over all
tems
> > of any license statements in the following files:....  "  ought to do
it.
> >
> > Bill
> >
> > On 9 Jun 2003 at 18:24, Bruce McDonald wrote:
> > > Bill, All:
> > >
> > > I would very much like to move babeldoc to a less restrictive license.
> > >  The big issue for me is the effort required to go through every
> > > source file and changing the header comment.  Any volunteers?
> > >
> > > regards,
> > > Bruce.
> > >
> > > On Monday 09 June 2003 02:13 pm, you wrote:
> > > > Bruce,
> > > >
> > > > I have been playing with BabelDoc for while now and find it very
> > > > useful, However, I have a commercial product that I want to combine
> > > > with it.  The chances of me being able to secure investment with
> > > > code combined under the GPL are vanishingly small.
> > > >
> > > > So, I would heartily endorse moving to the Apache Public License (as
> > > > quickly as possible, as I would like to release a new version of my
> > > > product within a month).  I currently have other Apache products in
> > > > my product and it would make my life a lot easier.  Otherwise I have
> > > > to figure out some "loose- coupling" of my product with BabelDoc
> > > > that makes the separation clear.  This would significantly restrict
> > > > the amount to which I could use it.
> > > >
> > > > ...one person's opinion, but I hope you will let me know what you
> > > > decide.
> > > >
> > > > regards and thanks for the great software,
> > > >
> > > > Bill
> > > >
> > > > On 23 May 2003 at 9:13, Bruce McDonald wrote:
> > > > > All,
> > > > >
> > > > > I have been thinking that trying to make babeldoc a Jakarta Apache
> > > > > project might be an excellent idea.  So instead of being one of
> > > > > 10000 projects on sourceforge we can be one of 50 on Jakarta.
> > > > > High visibility.  And since we use mainly Jakarta libraries, it
> > > > > would be a good fit.
> > > > >
> > > > > The issue is that we will have to re-license Babeldoc.  Now, in
> > > > > order to do so, we need to all agree on this.  The license is the
> > > > > Apache Public License.  This is more "liberal" than GPL in that
> > > > > code *can* be made commercial and does not limit the linking with
> > > > > proprietary code as much as GPL.  Your opinions and comments here
> > > > > are welcome.  Anyway the idea is to move the code in this
> > > > > direction.
> > > > >
> > > > > regards,
> > > > > Bruce McDonald.
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.net email is sponsored by: ObjectStore.
> > > > > If flattening out C++ or Java code to make your application fit in
> > > > > a relational database is painful, don't do it! Check out
> > > > > ObjectStore. Now part of Progress Software.
> > > > > http://www.objectstore.net/sourceforge
> > > > > _______________________________________________ Babeldoc-devel
> > > > > mailing list Bab...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Proposal for all the babeldoc developers - CALL FOR VOTE

[Hans B. <ben...@ch...>]

On Mon, 9 Jun 2003, Bruce McDonald wrote:

> Yes, you are right - it is a job for perl - I will do the script.  Thanks for
> your input Ken.

In case you haven't started yet: It could also be a job for jalopy. And if
we touch and recommit all the files anyway, it would be a good moment to
add the jalopy target to the build files.

By the way, Apache Public License is o.k. for me.

Hans

>
> On Monday 09 June 2003 11:21 pm, Ken Geis wrote:
> > +1
> >
> > A quick scan tells me that only 25 files actually have a copyright
> > statement on them.  I believe that the only claimants are Bruce and
> > Dejan.  So I think it only requires their permission, but I am glad that
> > you bring it to vote.
> >
> > A license such as the Apache Public License would clear up some issues
> > for us.  About changing the license headers...  Aren't we all text
> > processors here, guys?!?  That sounds like a job for Perl (although I
> > don't really know Perl!)
> >
> > I am more hesitant towards the idea of becoming a Jakarta project; I
> > just don't see the need, and I think it needs more cleaning up first.
> >
> >
> > Ken
> >
> > Bruce McDonald wrote:
> > > I am leaning towards the Apache Public License - what do you think?  We
> > > need a vote one this.  Every who dis/agrees that a license change is in
> > > order, please respond yes or no.  If yes, please provide your opinion on
> > > the new license (if you have an opinion).  Voting closes this friday.
> > >
> > > On Monday 09 June 2003 08:38 pm, Bill Harrelson wrote:
> > >>How about just including a blanket statement in one README file with a
> > >> date that overrides all headers in any file dated prior to the included
> > >> date? Then just update the headers one-by-one as they are touched?
> > >>
> > >>Language like "This license supersedes and takes precedence over all tems
> > >>of any license statements in the following files:....  "  ought to do it.
> > >>
> > >>Bill
> > >>
> > >>On 9 Jun 2003 at 18:24, Bruce McDonald wrote:
> > >>>Bill, All:
> > >>>
> > >>>I would very much like to move babeldoc to a less restrictive license.
> > >>> The big issue for me is the effort required to go through every
> > >>>source file and changing the header comment.  Any volunteers?
> > >>>
> > >>>regards,
> > >>>Bruce.
> > >>>
> > >>>On Monday 09 June 2003 02:13 pm, you wrote:
> > >>>>Bruce,
> > >>>>
> > >>>>I have been playing with BabelDoc for while now and find it very
> > >>>>useful, However, I have a commercial product that I want to combine
> > >>>>with it.  The chances of me being able to secure investment with
> > >>>>code combined under the GPL are vanishingly small.
> > >>>>
> > >>>>So, I would heartily endorse moving to the Apache Public License (as
> > >>>>quickly as possible, as I would like to release a new version of my
> > >>>>product within a month).  I currently have other Apache products in
> > >>>>my product and it would make my life a lot easier.  Otherwise I have
> > >>>>to figure out some "loose- coupling" of my product with BabelDoc
> > >>>>that makes the separation clear.  This would significantly restrict
> > >>>>the amount to which I could use it.
> > >>>>
> > >>>>...one person's opinion, but I hope you will let me know what you
> > >>>>decide.
> > >>>>
> > >>>>regards and thanks for the great software,
> > >>>>
> > >>>>Bill
> > >>>>
> > >>>>On 23 May 2003 at 9:13, Bruce McDonald wrote:
> > >>>>>All,
> > >>>>>
> > >>>>>I have been thinking that trying to make babeldoc a Jakarta Apache
> > >>>>>project might be an excellent idea.  So instead of being one of
> > >>>>>10000 projects on sourceforge we can be one of 50 on Jakarta.
> > >>>>>High visibility.  And since we use mainly Jakarta libraries, it
> > >>>>>would be a good fit.
> > >>>>>
> > >>>>>The issue is that we will have to re-license Babeldoc.  Now, in
> > >>>>>order to do so, we need to all agree on this.  The license is the
> > >>>>>Apache Public License.  This is more "liberal" than GPL in that
> > >>>>>code *can* be made commercial and does not limit the linking with
> > >>>>>proprietary code as much as GPL.  Your opinions and comments here
> > >>>>>are welcome.  Anyway the idea is to move the code in this
> > >>>>>direction.
> > >>>>>
> > >>>>>regards,
> > >>>>>Bruce McDonald.
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> > thread debugger on the planet. Designed with thread debugging features
> > you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>

Re: [Babeldoc-devel] Proposal for all the babeldoc developers - CALL FOR VOTE

[Bruce M. <br...@mc...>]

Yes, you are right - it is a job for perl - I will do the script.  Thanks for 
your input Ken.

On Monday 09 June 2003 11:21 pm, Ken Geis wrote:
> +1
>
> A quick scan tells me that only 25 files actually have a copyright
> statement on them.  I believe that the only claimants are Bruce and
> Dejan.  So I think it only requires their permission, but I am glad that
> you bring it to vote.
>
> A license such as the Apache Public License would clear up some issues
> for us.  About changing the license headers...  Aren't we all text
> processors here, guys?!?  That sounds like a job for Perl (although I
> don't really know Perl!)
>
> I am more hesitant towards the idea of becoming a Jakarta project; I
> just don't see the need, and I think it needs more cleaning up first.
>
>
> Ken
>
> Bruce McDonald wrote:
> > I am leaning towards the Apache Public License - what do you think?  We
> > need a vote one this.  Every who dis/agrees that a license change is in
> > order, please respond yes or no.  If yes, please provide your opinion on
> > the new license (if you have an opinion).  Voting closes this friday.
> >
> > On Monday 09 June 2003 08:38 pm, Bill Harrelson wrote:
> >>How about just including a blanket statement in one README file with a
> >> date that overrides all headers in any file dated prior to the included
> >> date? Then just update the headers one-by-one as they are touched?
> >>
> >>Language like "This license supersedes and takes precedence over all tems
> >>of any license statements in the following files:....  "  ought to do it.
> >>
> >>Bill
> >>
> >>On 9 Jun 2003 at 18:24, Bruce McDonald wrote:
> >>>Bill, All:
> >>>
> >>>I would very much like to move babeldoc to a less restrictive license.
> >>> The big issue for me is the effort required to go through every
> >>>source file and changing the header comment.  Any volunteers?
> >>>
> >>>regards,
> >>>Bruce.
> >>>
> >>>On Monday 09 June 2003 02:13 pm, you wrote:
> >>>>Bruce,
> >>>>
> >>>>I have been playing with BabelDoc for while now and find it very
> >>>>useful, However, I have a commercial product that I want to combine
> >>>>with it.  The chances of me being able to secure investment with
> >>>>code combined under the GPL are vanishingly small.
> >>>>
> >>>>So, I would heartily endorse moving to the Apache Public License (as
> >>>>quickly as possible, as I would like to release a new version of my
> >>>>product within a month).  I currently have other Apache products in
> >>>>my product and it would make my life a lot easier.  Otherwise I have
> >>>>to figure out some "loose- coupling" of my product with BabelDoc
> >>>>that makes the separation clear.  This would significantly restrict
> >>>>the amount to which I could use it.
> >>>>
> >>>>...one person's opinion, but I hope you will let me know what you
> >>>>decide.
> >>>>
> >>>>regards and thanks for the great software,
> >>>>
> >>>>Bill
> >>>>
> >>>>On 23 May 2003 at 9:13, Bruce McDonald wrote:
> >>>>>All,
> >>>>>
> >>>>>I have been thinking that trying to make babeldoc a Jakarta Apache
> >>>>>project might be an excellent idea.  So instead of being one of
> >>>>>10000 projects on sourceforge we can be one of 50 on Jakarta.
> >>>>>High visibility.  And since we use mainly Jakarta libraries, it
> >>>>>would be a good fit.
> >>>>>
> >>>>>The issue is that we will have to re-license Babeldoc.  Now, in
> >>>>>order to do so, we need to all agree on this.  The license is the
> >>>>>Apache Public License.  This is more "liberal" than GPL in that
> >>>>>code *can* be made commercial and does not limit the linking with
> >>>>>proprietary code as much as GPL.  Your opinions and comments here
> >>>>>are welcome.  Anyway the idea is to move the code in this
> >>>>>direction.
> >>>>>
> >>>>>regards,
> >>>>>Bruce McDonald.
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Proposal for all the babeldoc developers - CALL FOR VOTE

[Ken G. <kg...@sp...>]

+1

A quick scan tells me that only 25 files actually have a copyright 
statement on them.  I believe that the only claimants are Bruce and 
Dejan.  So I think it only requires their permission, but I am glad that 
you bring it to vote.

A license such as the Apache Public License would clear up some issues 
for us.  About changing the license headers...  Aren't we all text 
processors here, guys?!?  That sounds like a job for Perl (although I 
don't really know Perl!)

I am more hesitant towards the idea of becoming a Jakarta project; I 
just don't see the need, and I think it needs more cleaning up first.


Ken

Bruce McDonald wrote:
> I am leaning towards the Apache Public License - what do you think?  We need a 
> vote one this.  Every who dis/agrees that a license change is in order, 
> please respond yes or no.  If yes, please provide your opinion on the new 
> license (if you have an opinion).  Voting closes this friday.
> 
> On Monday 09 June 2003 08:38 pm, Bill Harrelson wrote:
> 
>>How about just including a blanket statement in one README file with a date
>>that overrides all headers in any file dated prior to the included date? 
>>Then just update the headers one-by-one as they are touched?
>>
>>Language like "This license supersedes and takes precedence over all tems
>>of any license statements in the following files:....  "  ought to do it.
>>
>>Bill
>>
>>On 9 Jun 2003 at 18:24, Bruce McDonald wrote:
>>
>>>Bill, All:
>>>
>>>I would very much like to move babeldoc to a less restrictive license.
>>> The big issue for me is the effort required to go through every
>>>source file and changing the header comment.  Any volunteers?
>>>
>>>regards,
>>>Bruce.
>>>
>>>On Monday 09 June 2003 02:13 pm, you wrote:
>>>
>>>>Bruce,
>>>>
>>>>I have been playing with BabelDoc for while now and find it very
>>>>useful, However, I have a commercial product that I want to combine
>>>>with it.  The chances of me being able to secure investment with
>>>>code combined under the GPL are vanishingly small.
>>>>
>>>>So, I would heartily endorse moving to the Apache Public License (as
>>>>quickly as possible, as I would like to release a new version of my
>>>>product within a month).  I currently have other Apache products in
>>>>my product and it would make my life a lot easier.  Otherwise I have
>>>>to figure out some "loose- coupling" of my product with BabelDoc
>>>>that makes the separation clear.  This would significantly restrict
>>>>the amount to which I could use it.
>>>>
>>>>...one person's opinion, but I hope you will let me know what you
>>>>decide.
>>>>
>>>>regards and thanks for the great software,
>>>>
>>>>Bill
>>>>
>>>>On 23 May 2003 at 9:13, Bruce McDonald wrote:
>>>>
>>>>>All,
>>>>>
>>>>>I have been thinking that trying to make babeldoc a Jakarta Apache
>>>>>project might be an excellent idea.  So instead of being one of
>>>>>10000 projects on sourceforge we can be one of 50 on Jakarta.
>>>>>High visibility.  And since we use mainly Jakarta libraries, it
>>>>>would be a good fit.
>>>>>
>>>>>The issue is that we will have to re-license Babeldoc.  Now, in
>>>>>order to do so, we need to all agree on this.  The license is the
>>>>>Apache Public License.  This is more "liberal" than GPL in that
>>>>>code *can* be made commercial and does not limit the linking with
>>>>>proprietary code as much as GPL.  Your opinions and comments here
>>>>>are welcome.  Anyway the idea is to move the code in this
>>>>>direction.
>>>>>
>>>>>regards,
>>>>>Bruce McDonald.

Re: [Babeldoc-devel] Proposal for all the babeldoc developers - CALL FOR VOTE

[Bruce M. <br...@mc...>]

I am leaning towards the Apache Public License - what do you think?  We need a 
vote one this.  Every who dis/agrees that a license change is in order, 
please respond yes or no.  If yes, please provide your opinion on the new 
license (if you have an opinion).  Voting closes this friday.

On Monday 09 June 2003 08:38 pm, Bill Harrelson wrote:
> How about just including a blanket statement in one README file with a date
> that overrides all headers in any file dated prior to the included date? 
> Then just update the headers one-by-one as they are touched?
>
> Language like "This license supersedes and takes precedence over all tems
> of any license statements in the following files:....  "  ought to do it.
>
> Bill
>
> On 9 Jun 2003 at 18:24, Bruce McDonald wrote:
> > Bill, All:
> >
> > I would very much like to move babeldoc to a less restrictive license.
> >  The big issue for me is the effort required to go through every
> > source file and changing the header comment.  Any volunteers?
> >
> > regards,
> > Bruce.
> >
> > On Monday 09 June 2003 02:13 pm, you wrote:
> > > Bruce,
> > >
> > > I have been playing with BabelDoc for while now and find it very
> > > useful, However, I have a commercial product that I want to combine
> > > with it.  The chances of me being able to secure investment with
> > > code combined under the GPL are vanishingly small.
> > >
> > > So, I would heartily endorse moving to the Apache Public License (as
> > > quickly as possible, as I would like to release a new version of my
> > > product within a month).  I currently have other Apache products in
> > > my product and it would make my life a lot easier.  Otherwise I have
> > > to figure out some "loose- coupling" of my product with BabelDoc
> > > that makes the separation clear.  This would significantly restrict
> > > the amount to which I could use it.
> > >
> > > ...one person's opinion, but I hope you will let me know what you
> > > decide.
> > >
> > > regards and thanks for the great software,
> > >
> > > Bill
> > >
> > > On 23 May 2003 at 9:13, Bruce McDonald wrote:
> > > > All,
> > > >
> > > > I have been thinking that trying to make babeldoc a Jakarta Apache
> > > > project might be an excellent idea.  So instead of being one of
> > > > 10000 projects on sourceforge we can be one of 50 on Jakarta.
> > > > High visibility.  And since we use mainly Jakarta libraries, it
> > > > would be a good fit.
> > > >
> > > > The issue is that we will have to re-license Babeldoc.  Now, in
> > > > order to do so, we need to all agree on this.  The license is the
> > > > Apache Public License.  This is more "liberal" than GPL in that
> > > > code *can* be made commercial and does not limit the linking with
> > > > proprietary code as much as GPL.  Your opinions and comments here
> > > > are welcome.  Anyway the idea is to move the code in this
> > > > direction.
> > > >
> > > > regards,
> > > > Bruce McDonald.
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by: ObjectStore.
> > > > If flattening out C++ or Java code to make your application fit in
> > > > a relational database is painful, don't do it! Check out
> > > > ObjectStore. Now part of Progress Software.
> > > > http://www.objectstore.net/sourceforge
> > > > _______________________________________________ Babeldoc-devel
> > > > mailing list Bab...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Babeldoc is (going to be) going through changes!

[Bruce M. <br...@mc...>]

Update.  The code is completed - there are no changes to the pipeline stages 
or the user code.

This code can definitely be generalized.  At the moment the hardest parts are 
converting between the piplinestageconfig objects and the ConfigOption 
objects.  The ScannerInfo classes can be easily done.  It is about a day of 
work.   The Gui classes are coming on nicely.

regards,
Bruce.

On Monday 09 June 2003 04:08 am, Dejan Krsmanovic wrote:
> I even thing this code could be generalized so it can be used not only with
> pipeline stages but with scanners, etc.
> We could have one common interface that would be implemented by components
> like pipeline stages, scanner workers. I did started working on
> this by creating IConfigurable iterface but have never finished it. Anyway,
> as a first step we can make this pipeline specific. Later we can
> decouple this code from pipeline stages and move it to some more general
> class....
>
> Dejan
>
> ----- Original Message -----
> From: "Ken Geis" <kg...@sp...>
> To: "Babeldoc Developer List" <bab...@li...>
> Sent: Monday, June 09, 2003 9:57 AM
> Subject: Re: [Babeldoc-devel] Babeldoc is (going to be) going through
> changes!
>
> > Dejan Krsmanovic wrote:
> > > I agree that we need better control over configuration parameters. We
> > > already have meta info object for each pipeline stage, so we just
> > > should
>
> use
>
> > > it!
> >
> > This is a better way to address the problems than I have in recent
> > commits.  If the factories checked the configuration, the code I wrote
> > to check options would not be necessary, and the metadata fixes I made
> > would have been caught sooner.
> >
> > We may have to remove some code if we make this change!  ;)
> >
> >
> > Ken
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> > thread debugger on the planet. Designed with thread debugging features
> > you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Babeldoc is (going to be) going through changes!

[Dejan K. <dej...@nb...>]

I even thing this code could be generalized so it can be used not only with
pipeline stages but with scanners, etc.
We could have one common interface that would be implemented by components
like pipeline stages, scanner workers. I did started working on
this by creating IConfigurable iterface but have never finished it. Anyway,
as a first step we can make this pipeline specific. Later we can
decouple this code from pipeline stages and move it to some more general
class....

Dejan

----- Original Message -----
From: "Ken Geis" <kg...@sp...>
To: "Babeldoc Developer List" <bab...@li...>
Sent: Monday, June 09, 2003 9:57 AM
Subject: Re: [Babeldoc-devel] Babeldoc is (going to be) going through
changes!


> Dejan Krsmanovic wrote:
> > I agree that we need better control over configuration parameters. We
> > already have meta info object for each pipeline stage, so we just should
use
> > it!
>
> This is a better way to address the problems than I have in recent
> commits.  If the factories checked the configuration, the code I wrote
> to check options would not be necessary, and the metadata fixes I made
> would have been caught sooner.
>
> We may have to remove some code if we make this change!  ;)
>
>
> Ken
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Babeldoc is (going to be) going through changes!

[Ken G. <kg...@sp...>]

Dejan Krsmanovic wrote:
> I agree that we need better control over configuration parameters. We
> already have meta info object for each pipeline stage, so we just should use
> it!

This is a better way to address the problems than I have in recent 
commits.  If the factories checked the configuration, the code I wrote 
to check options would not be necessary, and the metadata fixes I made 
would have been caught sooner.

We may have to remove some code if we make this change!  ;)


Ken

Re: [Babeldoc-devel] Babeldoc is (going to be) going through changes!

[Dejan K. <dej...@nb...>]

As I underestood, existing pipeline config files will not change? So users
will be used the same pipeline configuration they used before?
If this is true then you have my vote +1. It is important that users don't
need to change its configuration. Also, it would be nice if existing
pipeline stages don't need to be changed.

I agree that we need better control over configuration parameters. We
already have meta info object for each pipeline stage, so we just should use
it!

Is this change scheduled for 1.1 release?

Dejan


----- Original Message -----
From: "Bruce McDonald" <br...@mc...>
To: <bab...@li...>
Sent: Sunday, June 08, 2003 12:05 AM
Subject: [Babeldoc-devel] Babeldoc is (going to be) going through changes!


> All,
>
> With all the work on the GUI that I have been doing  (review the latest
cvs
> snapshot with the command:  "babeldoc pipelinebuilder" and go ahead and
> create a few pipelines)  I am going to have to change the configuration of
> pipelines.  This will roll to the scanner too, but lets get the pipelines
> working nicely.   At the moment we have this IConfigOptions object for
each
> pipeline stage.  This (should) provide information about the configuration
of
> the pipeline   stage.  I want to tie the actual configuration data to this
> object so that we can enforce things like isMandatory and isValid on the
> actual configuration values.  This will mean that the pipeline factory can
> actually check that the configuration is good before running the pipeline.
> This should mean that running a system will get easier.  So to recap - the
> underlying configuration of the pipelines from the PipelineStageResolver
code
> to the PipelineStage code will be changing.  No more nested Maps
nonsense -
> the data will be structured.
>
> Lets talk about how this will affect you.  At the moment I do not see that
the
> actual pipelinestage code will change - its just that the implementation
will
> change.  Email the list for questions / concerns.
>
> regards,
> Bruce.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

[Babeldoc-devel] Babeldoc is (going to be) going through changes!

[Bruce M. <br...@mc...>]

All,

With all the work on the GUI that I have been doing  (review the latest cvs 
snapshot with the command:  "babeldoc pipelinebuilder" and go ahead and 
create a few pipelines)  I am going to have to change the configuration of 
pipelines.  This will roll to the scanner too, but lets get the pipelines 
working nicely.   At the moment we have this IConfigOptions object for each 
pipeline stage.  This (should) provide information about the configuration of 
the pipeline   stage.  I want to tie the actual configuration data to this 
object so that we can enforce things like isMandatory and isValid on the 
actual configuration values.  This will mean that the pipeline factory can 
actually check that the configuration is good before running the pipeline.  
This should mean that running a system will get easier.  So to recap - the 
underlying configuration of the pipelines from the PipelineStageResolver code 
to the PipelineStage code will be changing.  No more nested Maps nonsense - 
the data will be structured.  

Lets talk about how this will affect you.  At the moment I do not see that the 
actual pipelinestage code will change - its just that the implementation will 
change.  Email the list for questions / concerns.

regards,
Bruce.

[Babeldoc-devel] new stuff being committed

[Bruce M. <br...@mc...>]

All,

I have been committing code for the Gui configuration tools and Dejan has been 
working on Scanners.  We will be needing to do a release of all the new code 
and therefore testing ...   We need volunteers for writing Unit test code - 
if you know a section well, unit tests would be appreciated.

In the meantime, please check out the Gui tools:

babeldoc pipelinebuilder
babeldoc setupwiz

Dejan:  I have committed the DiskQueuing code.  Take a look - I did a number 
of tests - multi- and single threaded and it all seems to work.

regards,
Bruce.

[Babeldoc-devel] Scanner and Feeders

[Dejan K. <dej...@nb...>]

Hi everybody!
I have just retuned from the conference were I had Babeldoc presentation
last week. There were about 50-100 people in the room during presentation
and it seems to me that I haven't been too boring ;-)

Anyway I am now fresh and ready for working on Babeldoc! We are planning to
have some modifications in the scanner module. In a few words, plan is to
separate processes for scaning and feeding documents. I have already written
some kind of queue and feeder implementations for documents, but after
reviewing Bruce's code for asynchronous feeder I have realized that there is
no need for another feeder implementation in scanner module. The biggest
difference between them is that mine implementation serializes documents so
in case of some crach, documents will not be lost. This is important in case
of e-mail messages because these messages have to be deleted from server
(pop3 protocol does not provide functionality for moving messages to
different folders). There are other situations, too. I think that this
feature is important so it should be implemented in core module, not just
scanner. So instead of subclasses Bruce's class I suggest adding serialize
functionality to basic AsynchronousFeeder class. Opinions?

Dejan

Re: [Babeldoc-devel] Requests

[Bruce M. <br...@mc...>]

Error handling in a sore point - this was our simplistic attempt at addressing 
this point


On Wednesday 28 May 2003 08:23 pm, Ken Geis wrote:
> Could someone...
>
> Update the Javadoc on
> com.babeldoc.core.pipeline.error.RedirectErrorHandler or get rid of the
> class?
>
> Write better documentation on when/how to call the processHelper methods
> in com.babeldoc.core.pipeline.PipelineStage?
>
>
> Thanks,
>
> Ken
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Updates

[Bruce M. <br...@mc...>]

I dont have access to oracle - check it in and lets see what happens.  Dejan 
has access to oracle.

On Wednesday 28 May 2003 08:17 pm, Ken Geis wrote:
> I'm checking in a bunch of updates right now.
>
> It seems like the console in 1.0 could not possibly work.  I've checked
> in what I needed to make it work.
>
> One change I might need some verification on.  In
> GenericSqlJournal.readDelta, I changed
>
> Blob blob = rset.getBlob(1);
> istream = blob.getBinaryStream();
>
> to
>
> istream = rset.getBinaryStream(1);
>
> The use of Blob seems unnecessary to me because we are not doing random
> access on that field.  I am assuming that this change will not break
> anything for MySQL or Oracle users, but I cannot be sure.  Please test
> it.  I am using PostgreSQL, and I defined that column as a bytea which
> is a (virtually) unlimited length binary field but is not a BLOB.
>
>
> Ken
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

[Babeldoc-devel] JournalTicket.toString()

[Ken G. <kg...@ga...>]

JournalTicket.toString() uses ToStringBuilder to give a string like

com.babeldoc.core.journal.
JournalTicket@2c14f9[value=214]

Some of the code is expecting this string to be just the journal ID (214 
in this case.)

Should toString() be made to return getId(), or should the calling code 
be changed to call getId() instead of toString()?


Ken

[Babeldoc-devel] Requests

[Ken G. <kg...@sp...>]

Could someone...

Update the Javadoc on 
com.babeldoc.core.pipeline.error.RedirectErrorHandler or get rid of the 
class?

Write better documentation on when/how to call the processHelper methods 
in com.babeldoc.core.pipeline.PipelineStage?


Thanks,

Ken

[Babeldoc-devel] Updates

[Ken G. <kg...@sp...>]

I'm checking in a bunch of updates right now.

It seems like the console in 1.0 could not possibly work.  I've checked 
in what I needed to make it work.

One change I might need some verification on.  In 
GenericSqlJournal.readDelta, I changed

Blob blob = rset.getBlob(1);
istream = blob.getBinaryStream();

to

istream = rset.getBinaryStream(1);

The use of Blob seems unnecessary to me because we are not doing random 
access on that field.  I am assuming that this change will not break 
anything for MySQL or Oracle users, but I cannot be sure.  Please test 
it.  I am using PostgreSQL, and I defined that column as a bytea which 
is a (virtually) unlimited length binary field but is not a BLOB.


Ken

Re: [Babeldoc-devel] SOAP

[Bruce M. <br...@mc...>]

Hans,

Regarding your point of sending documents as attachments - it is well made.  I 
would rather send XML documents as body elements as opposed to attachments 
except if the documents are binary or not xml.  I want to do this for the 
same reason as you - it just makes sense to do this.

Soap has a number of real advantages to RMI, IIOP, etc but the single most 
compelling one is that it runs on HTTP and can be moved through firewalls 
quite easily.  It also has a good mindshare, and that counts for a lot.

regards,
Bruce.

On Monday 26 May 2003 04:50 am, Hans Benedict wrote:
> Bruce,
>
> after sending my mail on friday, I remembered that one of my reasons for
> choosing jaxm/saaj was, that axis actually implements those interfaces.
>
> The only class that is implementation dependent, is SoapHelper which
> relies on dom4j for handling the body content. If we would really use the
> first "A" of saaj, i.e. "Attachments", we could make even this part
> implementation independent. This would also avoid potential namespace
> problems (what, if the name of the root element of our document ist named
> "Body" or "Envelope"...), but on the other hand it is strange somehow, to
> add an xml document to an xml document as an encoded binary attachment.
>
> I am finished with jaxm so far, that everything works as before. I wanted
> to add some more error handling (sending and understanding SoapFaults, for
> example), but haven't found the time yet.
>
> I do agree, that using soap as the remote mechanism of choice is a good
> idea. Allthough my real life experience with soap is only a couple of
> weeks old, I really enjoy the simplicity of connection different services
> even across programming language barriers. Unfortunately I have no idea
> how hard the impact on performance is.
>
> Regards,
> Hans
>
> On Sun, 25 May 2003, Bruce McDonald wrote:
> > Hans,
> >
> > No, that sounds fine.   Are all your efforts to JAXM complete?  I want to
> > expand the soap functionality within babeldoc a lot.  At the moment I
> > believe that we can make SOAP the remote mechanism of choice instead of
> > RMI, IIOP, etc.  What are your thoughts here?
> >
> > regards,
> > Bruce.
> >
> > On Friday 23 May 2003 09:53 am, Hans Benedict wrote:
> > > On Fri, 23 May 2003, Bruce McDonald wrote:
> > > > We should look into changing from soap4j to Axis for soap access.
> > > > Hans, since you seem to be the most knowledgeable in this area, what
> > > > are your opinions?
> > >
> > > After some discussions we had here, I have ported the soap module
> > > (which actually used apache soap) to jaxm/saaj completely.
> > >
> > > Do we use soap4j anywhere else?
> > >
> > > If you want to use an apache api for "political reasons" (becoming an
> > > apache project), I could propably also port it to axis.
> > >
> > > Regards,
> > > Hans
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: ObjectStore.
> > > If flattening out C++ or Java code to make your application fit in a
> > > relational database is painful, don't do it! Check out ObjectStore.
> > > Now part of Progress Software. http://www.objectstore.net/sourceforge
> > > _______________________________________________
> > > Babeldoc-devel mailing list
> > > Bab...@li...
> > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] SOAP

[Hans B. <ben...@ch...>]

Bruce,

after sending my mail on friday, I remembered that one of my reasons for
choosing jaxm/saaj was, that axis actually implements those interfaces.

The only class that is implementation dependent, is SoapHelper which
relies on dom4j for handling the body content. If we would really use the
first "A" of saaj, i.e. "Attachments", we could make even this part
implementation independent. This would also avoid potential namespace
problems (what, if the name of the root element of our document ist named
"Body" or "Envelope"...), but on the other hand it is strange somehow, to
add an xml document to an xml document as an encoded binary attachment.

I am finished with jaxm so far, that everything works as before. I wanted
to add some more error handling (sending and understanding SoapFaults, for
example), but haven't found the time yet.

I do agree, that using soap as the remote mechanism of choice is a good
idea. Allthough my real life experience with soap is only a couple of
weeks old, I really enjoy the simplicity of connection different services
even across programming language barriers. Unfortunately I have no idea
how hard the impact on performance is.

Regards,
Hans



On Sun, 25 May 2003, Bruce McDonald wrote:

> Hans,
>
> No, that sounds fine.   Are all your efforts to JAXM complete?  I want to
> expand the soap functionality within babeldoc a lot.  At the moment I believe
> that we can make SOAP the remote mechanism of choice instead of RMI, IIOP,
> etc.  What are your thoughts here?
>
> regards,
> Bruce.
>
> On Friday 23 May 2003 09:53 am, Hans Benedict wrote:
> > On Fri, 23 May 2003, Bruce McDonald wrote:
> > > We should look into changing from soap4j to Axis for soap access.
> > > Hans, since you seem to be the most knowledgeable in this area, what are
> > > your opinions?
> >
> > After some discussions we had here, I have ported the soap module (which
> > actually used apache soap) to jaxm/saaj completely.
> >
> > Do we use soap4j anywhere else?
> >
> > If you want to use an apache api for "political reasons" (becoming an
> > apache project), I could propably also port it to axis.
> >
> > Regards,
> > Hans
> >
> >
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software. http://www.objectstore.net/sourceforge
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>

Re: [Babeldoc-devel] SOAP

[Bruce M. <br...@mc...>]

Hans,

No, that sounds fine.   Are all your efforts to JAXM complete?  I want to 
expand the soap functionality within babeldoc a lot.  At the moment I believe 
that we can make SOAP the remote mechanism of choice instead of RMI, IIOP, 
etc.  What are your thoughts here?  

regards,
Bruce.

On Friday 23 May 2003 09:53 am, Hans Benedict wrote:
> On Fri, 23 May 2003, Bruce McDonald wrote:
> > We should look into changing from soap4j to Axis for soap access.
> > Hans, since you seem to be the most knowledgeable in this area, what are
> > your opinions?
>
> After some discussions we had here, I have ported the soap module (which
> actually used apache soap) to jaxm/saaj completely.
>
> Do we use soap4j anywhere else?
>
> If you want to use an apache api for "political reasons" (becoming an
> apache project), I could propably also port it to axis.
>
> Regards,
> Hans
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Building Babeldoc 1.1

[Dejan K. <dej...@nb...>]

You were right. I did clean update and it does compile now...
Dejan

----- Original Message ----- 
From: "Bruce McDonald" <br...@mc...>
To: "Dejan Krsmanovic" <dej...@nb...>; "Babeldoc Developers List"
<bab...@li...>
Sent: Friday, May 23, 2003 3:26 PM
Subject: Re: [Babeldoc-devel] Building Babeldoc 1.1


> Dejan,
>
> As much as I hate to say this, but I have confirmed that it builds here.
I
> have done in this a seperate check-out directory and in the development
> directory.  Maybe its a windows issue - I am doing all my development on
> Linux at this time.
>
> Good luck.
>
> regards,
> Bruce
>
> PS.  OFF to work - talk via YIM!
>
> On Friday 23 May 2003 09:02 am, Dejan Krsmanovic wrote:
> > I have latest code....
> > I don't know what is the problem...
> >
> > Dejan
> >
> > ----- Original Message -----
> > From: "Bruce McDonald" <br...@mc...>
> > To: "Dejan Krsmanovic" <dej...@nb...>; "Babeldoc Developers
> > List" <bab...@li...>
> > Sent: Friday, May 23, 2003 2:50 PM
> > Subject: Re: [Babeldoc-devel] Building Babeldoc 1.1
> >
> > > Dejan,
> > >
> > > Building should be no problem - the module building code did not
change
> > > at
> >
> > all
> >
> > > - its just the runtime module code.  please make sure that you have
the
> > > latest code.  regards,
> > > Bruce.
> > >
> > > On Friday 23 May 2003 08:41 am, Dejan Krsmanovic wrote:
> > > > Bruce,
> > > > is there changes in building mechanism in HEAD branch? I cannot
build
> >
> > using
> >
> > > > build.bat. I got following error:
> > > >
> > > >
> > > > Buildfile: build.xml
> > > >
> > > > declare:
> > > >
> > > > depends:
> > > >
> > > > BUILD FAILED
> > > > file:D:/eclipse/workspace/BabeldocSF/build.xml:89: No modules found!
> > > >
> > > >
> > > > I guess it is due to change of module mechanism. Have you any tip
for
> > > > building?
> > > >
> > > > Dejan
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by: ObjectStore.
> > > > If flattening out C++ or Java code to make your application fit in a
> > > > relational database is painful, don't do it! Check out ObjectStore.
> > > > Now part of Progress Software.
http://www.objectstore.net/sourceforge
> > > > _______________________________________________
> > > > Babeldoc-devel mailing list
> > > > Bab...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software. http://www.objectstore.net/sourceforge
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] SOAP

[Hans B. <ben...@ch...>]

On Fri, 23 May 2003, Bruce McDonald wrote:

> We should look into changing from soap4j to Axis for soap access.
> Hans, since you seem to be the most knowledgeable in this area, what are
> your opinions?

After some discussions we had here, I have ported the soap module (which
actually used apache soap) to jaxm/saaj completely.

Do we use soap4j anywhere else?

If you want to use an apache api for "political reasons" (becoming an
apache project), I could propably also port it to axis.

Regards,
Hans

[Babeldoc-devel] 1.0.1 version

[Dejan K. <dej...@nb...>]

Bruce,
do you plan to do 1.0.1 release today? I have commited all bugfixes that I
had.
Dejan