Re: [Babeldoc-devel] On how to commit

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

On how to commitHi Vincent


> - The addMessage tin the error handler saves the complete statck trace in
case of exception (with jakarta commans lang ExceptionUtils)



To be honest this method was a workaround for some problems I had (I needed
some way to inform users what happend to their document). I guess there are
better ways of doing it. At least, I don't like this method's name. But if
you have found this method usefull - feel free to change it.

> - SmtpWriter will not add a Body in case smtpMessage is blank (A blank
body is not good, No body is better) : else that breaks smtp/x400 gateway



OK. I like that. I guess this won't break existing pipelines, right?

> - I added some velocity pages to see only failed tickets, and in general
to make the web console look a bit nicer.  This is a place where I ant to do
some more in the near future.



Cool. We need much improvements here. I think that part of Babeldoc is still
in the same state as before.

>  - The Lock mechanism on FtpWriter : optional parameter to send a lock
file before sending the file and look if it does not exist before sending
them



I guess it is OK as long as this stage works as before when locks are not
used.
>  - etc.
> Are you OK with these ?
> I have done all that on branch 1.0 so I want now to patch back the main
branch.


Excelent. I am OK with all these. Others? Vincent, could you also update
changes file?

> I have seen the changes on the scanner : It is great but at the same time,
running babeldoc in "synchronized" mode is sometimes more easy to debug
(else the threads gets mixed together) : Have you think a parameter at the
scanner level to force it to work "as before" in synchronize mode ?


Scanner module is still in development phase. I haven't switched all workers
to use new way of feeding. As you might noticed scanner works with IFeeder,
so it could work with Synchronous and Asynchronous feeder. It will use
ScannerFactory to get IFeeder implementation class. Right now, this method d
oes not use configuration file - it is hardcoded and it only returns new
Asynchronous feeder. But we plan to make that configurable, too.

What is your opinion is it better to keep this configuration in separate
file or it should be part of scanner configuration? Also, should this be
hardcoded (something like switch) or we should let users to specify its
implementation class like we do with ScanerWorkers? That way users will have
more freedom but currently I don't see some benefits of it!


All, note that 1.1 release will  be developmental - many new features but
not stable enough. I suggest we should soon release one stable version -
1.0.2 with Vincent's changes, and probably some other changes. Are you all
OK with that? Are there other changes/fixes we should put in this release?


Dejan