Menu
▾
▴
babeldoc-devel
|
From: <ek...@ba...> - 2003-04-22 13:13:56
|
<< One question Erik. When exception is thrown from PipeilneStageFactory methods, where it should be catched? In feeder? What is the real benefit of catching exception in feeder and not in PipelineStageFactory? Maybe you could get arround with your own ErrorHandler? >> The Exception should be thrown all the way up the program stack to the entry point. In my case, there will be an EJB calling PipelineFeeder.process( ) ... which coincidentally throws PipelineException ... which I would like to see the exceptions appear in. ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: <ek...@ba...> - 2003-04-22 13:49:06
|
<<
Then probably process method of PipelineStageFactory should throw
exception, right? I guess it is not enough if you use another
PipelineStageErrorHandler since it is used only for handling errors that
occurs in PipelineStage.process().
>>
Here is the call stack as I can trace it:
PipelineFeeder.process( ) throws PipelineException, JournalException
PipelineFactoryFactory.process( ) throws PipelineException
PipelineFactory.process( ) throws PipelineException
PipelineStageFactory.process( ) **which throws
nothing**
PipelineStageFactory.process( ) calls the following methods, which discard
the exceptions they catch:
-- getPipelineStage
-- trackDocument
As I looked at the programs above, I found more examples of exceptions
being caught and then either being discarded or having Error Log messages
generated.
I guess the question I have is: "If something is important enough to cause
an exception to be thrown, why is it so frequently sufficient to discard
the exception or replace it with a logged error message??"
I am going to search for more examples of this ... the production system I
implement cannot afford to have low-level exceptions discarded and I will
not be writing log-scanning software to search for errors in logs when it
could just as easily be identified by a thrown exception. Can anyone
explain this?
Erik
________________________________________________________________________
The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: Bruce M. <br...@mc...> - 2003-04-22 13:52:21
|
It can be explained by not having your set of requirements at the time of writing. You will probably need to implement the changes you need yourself. On Tuesday 22 April 2003 09:48 am, ek...@ba... wrote: > << > Then probably process method of PipelineStageFactory should throw > exception, right? I guess it is not enough if you use another > PipelineStageErrorHandler since it is used only for handling errors that > occurs in PipelineStage.process(). > > > Here is the call stack as I can trace it: > > PipelineFeeder.process( ) throws PipelineException, JournalException > PipelineFactoryFactory.process( ) throws PipelineException > PipelineFactory.process( ) throws PipelineException > PipelineStageFactory.process( ) **which throws > nothing** > > PipelineStageFactory.process( ) calls the following methods, which discard > the exceptions they catch: > -- getPipelineStage > -- trackDocument > > As I looked at the programs above, I found more examples of exceptions > being caught and then either being discarded or having Error Log messages > generated. > > I guess the question I have is: "If something is important enough to cause > an exception to be thrown, why is it so frequently sufficient to discard > the exception or replace it with a logged error message??" > > I am going to search for more examples of this ... the production system I > implement cannot afford to have low-level exceptions discarded and I will > not be writing log-scanning software to search for errors in logs when it > could just as easily be identified by a thrown exception. Can anyone > explain this? > > Erik > > ________________________________________________________________________ > The information in this e-mail, and any attachment therein, is confidential > and for use by the addressee only. If you are not the intended recipient, > please return the e-mail to the sender and delete it from your computer. > Although The Bank of New York attempts to sweep e-mail and attachments for > viruses, it does not guarantee that either are virus-free and accepts no > liability for any damage sustained as a result of viruses. |
|
From: Dejan K. <dej...@nb...> - 2003-04-22 13:58:08
|
I agree with you that these two methods should throw exceptions. These =
are serious problems and exception should not be discarded. If you =
asking me, feel free to implement this.=20
Dejan
----- Original Message -----=20
From: ek...@ba...=20
To: bab...@li...=20
Sent: Tuesday, April 22, 2003 3:48 PM
Subject: Re: [Babeldoc-devel] PipelineStageFactory
<<=20
Then probably process method of PipelineStageFactory should throw =
exception, right? I guess it is not enough if you use another =
PipelineStageErrorHandler since it is used only for handling errors that =
occurs in PipelineStage.process().
>>=20
Here is the call stack as I can trace it:=20
PipelineFeeder.process( ) throws PipelineException, JournalException=20
PipelineFactoryFactory.process( ) throws PipelineException=20
PipelineFactory.process( ) throws PipelineException=20
PipelineStageFactory.process( ) **which throws =
nothing**=20
PipelineStageFactory.process( ) calls the following methods, which =
discard the exceptions they catch:=20
-- getPipelineStage=20
-- trackDocument=20
As I looked at the programs above, I found more examples of exceptions =
being caught and then either being discarded or having Error Log =
messages generated.=20
I guess the question I have is: "If something is important enough to =
cause an exception to be thrown, why is it so frequently sufficient to =
discard the exception or replace it with a logged error message??"=20
I am going to search for more examples of this ... the production =
system I implement cannot afford to have low-level exceptions discarded =
and I will not be writing log-scanning software to search for errors in =
logs when it could just as easily be identified by a thrown exception. =
Can anyone explain this?=20
Erik=20
=
________________________________________________________________________
The information in this e-mail, and any attachment therein, is =
confidential and for use by the addressee only. If you are not the =
intended recipient, please return the e-mail to the sender and delete it =
from your computer. Although The Bank of New York attempts to sweep =
e-mail and attachments for viruses, it does not guarantee that either =
are virus-free and accepts no liability for any damage sustained as a =
result of viruses.
|
|
From: <ek...@ba...> - 2003-04-22 13:57:07
|
<< It can be explained by not having your set of requirements at the time of writing. You will probably need to implement the changes you need yourself. >> Understood. Not a problem. So, shall I implement these changes in the codebase or do I need to diverge from the codebase at this point in time? Note: I suspect we may find things that "break" once the exceptions start flowing through the call stack. Additionally, I'm sure there are a few truly legitimate places where the exceptions are not important and processing handles this. If there is any insight into examples of these, please advise. Erik ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: Bruce M. <br...@mc...> - 2003-04-22 14:04:36
|
Erik, all, Comments inline. On Tuesday 22 April 2003 09:56 am, ek...@ba... wrote: > << > It can be explained by not having your set of requirements at the time of > writing. You will probably need to implement the changes you need > yourself. > > > Understood. Not a problem. > > So, shall I implement these changes in the codebase or do I need to > diverge from the codebase at this point in time? No, dont fork the codebase, let the exceptions move up the stack - just make sure that they get caught "somewhere". The "somewhere" in the case of PipelineFeeder.process is ultimately called from PipelineFeeder.execute. In this case all the possible exceptions are caught so all is well. > Note: I suspect we may find things that "break" once the exceptions start > flowing through the call stack. This is probably a good thing - we will need to fix theses places. > Additionally, I'm sure there are a few truly legitimate places where the > exceptions are not important and processing handles this. If there is any > insight into examples of these, please advise. Lets deal with that when we find them. Sorry to be not specific. > Erik > > ________________________________________________________________________ > The information in this e-mail, and any attachment therein, is confidential > and for use by the addressee only. If you are not the intended recipient, > please return the e-mail to the sender and delete it from your computer. > Although The Bank of New York attempts to sweep e-mail and attachments for > viruses, it does not guarantee that either are virus-free and accepts no > liability for any damage sustained as a result of viruses. |
|
From: Dejan K. <dej...@nb...> - 2003-04-22 14:37:29
|
I will handle scanner part, since I am working on it these days anyway Dejan > No, dont fork the codebase, let the exceptions move up the stack - just make > sure that they get caught "somewhere". The "somewhere" in the case of > PipelineFeeder.process is ultimately called from PipelineFeeder.execute. In > this case all the possible exceptions are caught so all is well. > |
|
From: <ek...@ba...> - 2003-04-22 14:47:28
|
<<
No, dont fork the codebase, let the exceptions move up the stack - just
make
sure that they get caught "somewhere". The "somewhere" in the case of
PipelineFeeder.process is ultimately called from PipelineFeeder.execute.
In
this case all the possible exceptions are caught so all is well.
>>
My suggestion was either for me to modify the codebase or for ME to break
away from the codebase and develop independently. I had no intention of
forking the codebase within CVS (if that is what you meant).
As to catching the exception "somewhere", I personally feel that the
system should expose certain "high-level / client-consumable" exceptions
through its entry points. Otherwise, clients of this software (even
command-line processes) will not be aware of the errors occurring within
Babeldoc and can code to handle them. I am certainly no expert at the
exceptions being used in the software, but it seems to me that exceptions
such as PipelineException and JournalException seem "client consumable".
My approach would be the following:
1. Search out areas where exceptions are being discarded or just logged
2. Choose an "appropriate" exception class to represent the exception and
include this in the "throws" clause of the method signature.
3. Allow the compiler to identify all the calling methods which either
need to also "throw" these exceptions or take specific action to "trap and
handle" the exception
I just finished a quick analysis that identified every "catch" statement
in the entire codebase. Following are some statistics:
-- 289 catch statements
-- 157 of these either log the error or do printStackTrace ...
discarded
-- 33 of these do nothing ... discarded
-- 99 of these rethrow the exception "appropriately" ... handled
Not included in the numbers above are situations that obviously require no
exception handling (inability to close a database prepared statement /
connection, code that specifically documents that nothing should be done).
It should be noted that most of the Scanner, PipelineStage, and Journal
classes do a very good job of exception handling.
Please provide your thoughts on the following suggestion:
Since there are many places that simply log the error (using the
commons-logger), one "quick and dirty" approach would be to have the
underlying logging system throw a type of RuntimeException after the
logging has occurred when a logError request is made. This would mean
that no method signatures would need to be modified and exceptions would
flow straight to the top of the call stack. It would require very little
effort and would allow us to be one step closer to v1.0, but would not be
"as professional". Maybe this is a good stop-gap solution until 1.0 is
released.
What are your thoughts?
Erik
________________________________________________________________________
The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: Dejan K. <dej...@nb...> - 2003-04-22 14:59:33
|
This is not good idea. There are places where exceptions should be =
logged without rethrowing them. If I understood you, using your aproach =
would break processing whenever exception is logged. There are =
situations (like project that I am working on) where pipeline stage =
order depends on error that occured. In case of error, I need to send =
e-mail or something else, but breaking processing would not be good for =
me.
Anyway, there are really no many places where exceptions should be =
rethrown. getPipelineStage and trackDocument are good examples of =
methods that should rethrow exception... I think it would not be to hard =
to identify all or most of these methods.=20
Also, I don't think it is too important if 1.0 release would be delayed =
few weeks... Bruce when did you planned it, anyway?
Dejan
----- Original Message -----=20
From: ek...@ba...=20
To: bab...@li...=20
Sent: Tuesday, April 22, 2003 4:47 PM
Subject: Re: [Babeldoc-devel] PipelineStageFactory
<<=20
No, dont fork the codebase, let the exceptions move up the stack - =
just make
sure that they get caught "somewhere". The "somewhere" in the case of
PipelineFeeder.process is ultimately called from =
PipelineFeeder.execute. In
this case all the possible exceptions are caught so all is well.
>>=20
My suggestion was either for me to modify the codebase or for ME to =
break away from the codebase and develop independently. I had no =
intention of forking the codebase within CVS (if that is what you =
meant).=20
As to catching the exception "somewhere", I personally feel that the =
system should expose certain "high-level / client-consumable" exceptions =
through its entry points. Otherwise, clients of this software (even =
command-line processes) will not be aware of the errors occurring within =
Babeldoc and can code to handle them. I am certainly no expert at the =
exceptions being used in the software, but it seems to me that =
exceptions such as PipelineException and JournalException seem "client =
consumable".=20
My approach would be the following:=20
1. Search out areas where exceptions are being discarded or just =
logged=20
2. Choose an "appropriate" exception class to represent the exception =
and include this in the "throws" clause of the method signature.=20
3. Allow the compiler to identify all the calling methods which either =
need to also "throw" these exceptions or take specific action to "trap =
and handle" the exception=20
I just finished a quick analysis that identified every "catch" =
statement in the entire codebase. Following are some statistics:=20
-- 289 catch statements=20
-- 157 of these either log the error or do printStackTrace ... =
discarded=20
-- 33 of these do nothing ... discarded=20
-- 99 of these rethrow the exception "appropriately" ... =
handled=20
Not included in the numbers above are situations that obviously =
require no exception handling (inability to close a database prepared =
statement / connection, code that specifically documents that nothing =
should be done). It should be noted that most of the Scanner, =
PipelineStage, and Journal classes do a very good job of exception =
handling.=20
Please provide your thoughts on the following suggestion:=20
Since there are many places that simply log the error (using the =
commons-logger), one "quick and dirty" approach would be to have the =
underlying logging system throw a type of RuntimeException after the =
logging has occurred when a logError request is made. This would mean =
that no method signatures would need to be modified and exceptions would =
flow straight to the top of the call stack. It would require very =
little effort and would allow us to be one step closer to v1.0, but =
would not be "as professional". Maybe this is a good stop-gap solution =
until 1.0 is released.=20
What are your thoughts?=20
Erik=20
=
________________________________________________________________________
The information in this e-mail, and any attachment therein, is =
confidential and for use by the addressee only. If you are not the =
intended recipient, please return the e-mail to the sender and delete it =
from your computer. Although The Bank of New York attempts to sweep =
e-mail and attachments for viruses, it does not guarantee that either =
are virus-free and accepts no liability for any damage sustained as a =
result of viruses.
|
|
From: Bruce M. <br...@mc...> - 2003-04-22 16:48:20
|
Dejan, The release, all things being equal will go out on May 2 2003 regards, Bruce. On Tuesday 22 April 2003 10:56 am, Dejan Krsmanovic wrote: > This is not good idea. There are places where exceptions should be logged > without rethrowing them. If I understood you, using your aproach would > break processing whenever exception is logged. There are situations (like > project that I am working on) where pipeline stage order depends on error > that occured. In case of error, I need to send e-mail or something else, > but breaking processing would not be good for me. Anyway, there are really > no many places where exceptions should be rethrown. getPipelineStage and > trackDocument are good examples of methods that should rethrow exception... > I think it would not be to hard to identify all or most of these methods. > Also, I don't think it is too important if 1.0 release would be delayed few > weeks... Bruce when did you planned it, anyway? > > Dejan > > > ----- Original Message ----- > From: ek...@ba... > To: bab...@li... > Sent: Tuesday, April 22, 2003 4:47 PM > Subject: Re: [Babeldoc-devel] PipelineStageFactory > > > > << > No, dont fork the codebase, let the exceptions move up the stack - just > make sure that they get caught "somewhere". The "somewhere" in the case of > PipelineFeeder.process is ultimately called from PipelineFeeder.execute. > In this case all the possible exceptions are caught so all is well. > > > My suggestion was either for me to modify the codebase or for ME to break > away from the codebase and develop independently. I had no intention of > forking the codebase within CVS (if that is what you meant). > > As to catching the exception "somewhere", I personally feel that the > system should expose certain "high-level / client-consumable" exceptions > through its entry points. Otherwise, clients of this software (even > command-line processes) will not be aware of the errors occurring within > Babeldoc and can code to handle them. I am certainly no expert at the > exceptions being used in the software, but it seems to me that exceptions > such as PipelineException and JournalException seem "client consumable". > > My approach would be the following: > 1. Search out areas where exceptions are being discarded or just logged > 2. Choose an "appropriate" exception class to represent the exception and > include this in the "throws" clause of the method signature. 3. Allow the > compiler to identify all the calling methods which either need to also > "throw" these exceptions or take specific action to "trap and handle" the > exception > > I just finished a quick analysis that identified every "catch" statement > in the entire codebase. Following are some statistics: -- 289 catch > statements > -- 157 of these either log the error or do printStackTrace ... > discarded -- 33 of these do nothing ... discarded > -- 99 of these rethrow the exception "appropriately" ... handled > > Not included in the numbers above are situations that obviously require > no exception handling (inability to close a database prepared statement / > connection, code that specifically documents that nothing should be done). > It should be noted that most of the Scanner, PipelineStage, and Journal > classes do a very good job of exception handling. > > Please provide your thoughts on the following suggestion: > Since there are many places that simply log the error (using the > commons-logger), one "quick and dirty" approach would be to have the > underlying logging system throw a type of RuntimeException after the > logging has occurred when a logError request is made. This would mean that > no method signatures would need to be modified and exceptions would flow > straight to the top of the call stack. It would require very little effort > and would allow us to be one step closer to v1.0, but would not be "as > professional". Maybe this is a good stop-gap solution until 1.0 is > released. > > What are your thoughts? > > Erik > ________________________________________________________________________ > The information in this e-mail, and any attachment therein, is > confidential and for use by the addressee only. If you are not the intended > recipient, please return the e-mail to the sender and delete it from your > computer. Although The Bank of New York attempts to sweep e-mail and > attachments for viruses, it does not guarantee that either are virus-free > and accepts no liability for any damage sustained as a result of viruses. |
|
From: Dejan K. <dej...@ya...> - 2003-04-22 19:30:17
|
If you asking me I would not hurry with this realase. We do plan some changes in core module that could impact on all other modules. I guess there will be more changes like this since requirements that Erik has are pretty different than those that you had when you have started to write Babeldoc and those that I had in my projects. This will require a lot of testing. Some aspects that was not important for us will be important for Erik's project so he will probably do more changes (which is good thing because it will improve Babeldoc and make it applicable to problems that was not initialy planned). Also, note that I will be on vacation between April 25th and May 5th. Dejan --- Bruce McDonald <br...@mc...> wrote: > Dejan, > > The release, all things being equal will go out on > May 2 2003 > > regards, > Bruce. > __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com |
|
From: <ek...@ba...> - 2003-04-22 19:45:36
|
Gentlemen, the last thing I want to do is be the cause of the delay of the initial release. I "walked onto" this project very late in your development cycle and have been quite a drain on your resources in order to get the assistance I need in implementing this for my purposes. I never expected the software to be "custom built" for my needs. The product will never be "all things to all people". The issue of Exceptions may be a touchy one ... I certainly don't want to go around changing the method signatures of the majority of methods in the system if the current functionality meets most people's needs right now. Whether I discovered a rare instance of an exception not being handled well or if this "issue" is propogated all throughout the system, I have no idea. I get the impression that what I've proposed today may be a bigger modification than is desired at this point. As you are aware, I have incredibly tight deadlines for production implementation (less than 4 weeks at this point) and hence may not be able to provide the type of "community support" that most other participants in an open-source project can provide. And I don't want other people spending their time and effort making modifications solely for my consumption. I am equally open to the following options: 1. Me implementing my own Logging extension that throws a RuntimeException whenever an Error Log request is made, thereby affecting no one else 2. Us investigating which discarded exceptions are legitimate and which need to be addressed and dividing the work to do it ... this can take a tremendous amount of analysis for someone not familiar with the codebase 3. Me diverging from the codebase at this point, implementing my own exception handling, and perhaps merging back after 1.0 is released. I'm open to any of the above. Bruce, I look to you for guidance on this. Thanks. Erik Sent by: bab...@li... To: bab...@li... cc: Subject: Re: [Babeldoc-devel] PipelineStageFactory If you asking me I would not hurry with this realase. We do plan some changes in core module that could impact on all other modules. I guess there will be more changes like this since requirements that Erik has are pretty different than those that you had when you have started to write Babeldoc and those that I had in my projects. This will require a lot of testing. Some aspects that was not important for us will be important for Erik's project so he will probably do more changes (which is good thing because it will improve Babeldoc and make it applicable to problems that was not initialy planned). Also, note that I will be on vacation between April 25th and May 5th. Dejan --- Bruce McDonald <br...@mc...> wrote: > Dejan, > > The release, all things being equal will go out on > May 2 2003 > > regards, > Bruce. > __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Babeldoc-devel mailing list Bab...@li... https://lists.sourceforge.net/lists/listinfo/babeldoc-devel ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
|
From: Bruce M. <br...@mc...> - 2003-04-22 19:50:59
|
Erik, all, I am quite open to delaying the release of 1.0 until we have gotten this sorted out. I would prefer that we follow your efforts so that we may immediately reap the benefits of your work. Basically I agree with Dejan here - we need not rush to 1.0 after moving patiently for this long year. regards, Bruce. On Tuesday 22 April 2003 03:45 pm, ek...@ba... wrote: > Gentlemen, the last thing I want to do is be the cause of the delay of the > initial release. I "walked onto" this project very late in your > development cycle and have been quite a drain on your resources in order > to get the assistance I need in implementing this for my purposes. I > never expected the software to be "custom built" for my needs. The > product will never be "all things to all people". > > The issue of Exceptions may be a touchy one ... I certainly don't want to > go around changing the method signatures of the majority of methods in the > system if the current functionality meets most people's needs right now. > Whether I discovered a rare instance of an exception not being handled > well or if this "issue" is propogated all throughout the system, I have no > idea. I get the impression that what I've proposed today may be a bigger > modification than is desired at this point. > > As you are aware, I have incredibly tight deadlines for production > implementation (less than 4 weeks at this point) and hence may not be able > to provide the type of "community support" that most other participants in > an open-source project can provide. And I don't want other people > spending their time and effort making modifications solely for my > consumption. > > I am equally open to the following options: > 1. Me implementing my own Logging extension that throws a RuntimeException > whenever an Error Log request is made, thereby affecting no one else > 2. Us investigating which discarded exceptions are legitimate and which > need to be addressed and dividing the work to do it ... this can take a > tremendous amount of analysis for someone not familiar with the codebase > 3. Me diverging from the codebase at this point, implementing my own > exception handling, and perhaps merging back after 1.0 is released. > > I'm open to any of the above. Bruce, I look to you for guidance on this. > Thanks. > > Erik > > > > Sent by: bab...@li... > To: bab...@li... > cc: > Subject: Re: [Babeldoc-devel] PipelineStageFactory > > > If you asking me I would not hurry with this realase. > > We do plan some changes in core module that could > impact on all other modules. I guess there will be > more changes like this since requirements that Erik > has are pretty different than those that you had when > you have started to write Babeldoc and those that I > had in my projects. This will require a lot of > testing. Some aspects that was not important for us > will be important for Erik's project so he will > probably do more changes (which is good thing because > it will improve Babeldoc and make it applicable to > problems that was not initialy planned). > > > > Also, note that I will be on vacation between April > 25th and May 5th. > > Dejan > > --- Bruce McDonald <br...@mc...> wrote: > > Dejan, > > > > The release, all things being equal will go out on > > May 2 2003 > > > > regards, > > Bruce. > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Babeldoc-devel mailing list > Bab...@li... > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel > > > > ________________________________________________________________________ > The information in this e-mail, and any attachment therein, is confidential > and for use by the addressee only. If you are not the intended recipient, > please return the e-mail to the sender and delete it from your computer. > Although The Bank of New York attempts to sweep e-mail and attachments for > viruses, it does not guarantee that either are virus-free and accepts no > liability for any damage sustained as a result of viruses. |
|
From: Dejan K. <dej...@nb...> - 2003-04-23 06:20:55
|
Erik, we don't have some kind of deadline for release so one or two weeks delaying will not cause problems. More important is improving Babeldoc's quality for that release. Anyway, your "incredibly tight deadline" means that we don't have to wait more than 4 weeks ;-) We know that you have no time to work anything that is not part of your project and I am OK with that. But, I do think that code inspections, suggestions and some bug fixes is helpful and important for us (at least for me!). I have few projects working on Babeldoc and we are plan few more serious projects and I am very interested to improve quality of this software. Be sure this software will not be "custom built for your needs" but anything we found iteresting to include or change in Babeldoc we will do if it doesn't break code compatibility. In other words, don't worry - nobody will do your job or something that will be applicable only to your project! So if we can delay our release (and Bruce said he is OK with that) I suggest choosing option 2. you have proposed since it is the best for Babeldoc. You should be aware that this option might be worst for you, because you will depend on other people and will have requirement to keep most code backward compatibile. Dejan ----- Original Message ----- From: ek...@ba... To: bab...@li... Sent: Tuesday, April 22, 2003 9:45 PM Subject: Re: [Babeldoc-devel] PipelineStageFactory Gentlemen, the last thing I want to do is be the cause of the delay of the initial release. I "walked onto" this project very late in your development cycle and have been quite a drain on your resources in order to get the assistance I need in implementing this for my purposes. I never expected the software to be "custom built" for my needs. The product will never be "all things to all people". The issue of Exceptions may be a touchy one ... I certainly don't want to go around changing the method signatures of the majority of methods in the system if the current functionality meets most people's needs right now. Whether I discovered a rare instance of an exception not being handled well or if this "issue" is propogated all throughout the system, I have no idea. I get the impression that what I've proposed today may be a bigger modification than is desired at this point. As you are aware, I have incredibly tight deadlines for production implementation (less than 4 weeks at this point) and hence may not be able to provide the type of "community support" that most other participants in an open-source project can provide. And I don't want other people spending their time and effort making modifications solely for my consumption. I am equally open to the following options: 1. Me implementing my own Logging extension that throws a RuntimeException whenever an Error Log request is made, thereby affecting no one else 2. Us investigating which discarded exceptions are legitimate and which need to be addressed and dividing the work to do it ... this can take a tremendous amount of analysis for someone not familiar with the codebase 3. Me diverging from the codebase at this point, implementing my own exception handling, and perhaps merging back after 1.0 is released. I'm open to any of the above. Bruce, I look to you for guidance on this. Thanks. Erik Sent by: bab...@li... To: bab...@li... cc: Subject: Re: [Babeldoc-devel] PipelineStageFactory If you asking me I would not hurry with this realase. We do plan some changes in core module that could impact on all other modules. I guess there will be more changes like this since requirements that Erik has are pretty different than those that you had when you have started to write Babeldoc and those that I had in my projects. This will require a lot of testing. Some aspects that was not important for us will be important for Erik's project so he will probably do more changes (which is good thing because it will improve Babeldoc and make it applicable to problems that was not initialy planned). Also, note that I will be on vacation between April 25th and May 5th. Dejan --- Bruce McDonald <br...@mc...> wrote: > Dejan, > > The release, all things being equal will go out on > May 2 2003 > > regards, > Bruce. > __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Babeldoc-devel mailing list Bab...@li... https://lists.sourceforge.net/lists/listinfo/babeldoc-devel ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. |
Thanks for helping keep SourceForge clean.
X