babeldoc-devel — Babeldoc developer list

Re: [Babeldoc-devel] Database Tables

[<ek...@ba...>]

<<
> We add another configuration parameter to the XslTransform that
provides
> the
> XSL document inline.  This will be in addition to the file
configuration
> parameter.  So the logic is:
>
> 1.  If the file/url parameter is not null, load from the url
> 2.  if the inline parameter is not null, use the XSL in the parameter
>
>
> I'm not sure of the method signature that would take this, but is it
> possible to have an overloaded implementation that has one method that
> takes a URL and another that takes a String?

No, we have another configuration parameter for the XslTransform
pipeline
stage called, say transformationScript.  This contains the script inline

> Also, how would this information be stored in the Properties Files /
> CONFIG table?  An additional key/value pair or column?  Or are you
> thinking of using the existing key / cfg_value field to store EITHER
the
> URL or the actual script?  If this is your choice, the db schema has
to
> change to support more than 255 chars.

Bingo - we will have to increase the storage area.  The script will get
stored
in the cfg_value column.
>>

Sounds good to me.  However, I feel strongly that the database fields
needs to be an unlimited length text field, which may require special
JDBC processing like you have for BLOBs ... but I was under the
assumption that JDBC 2.0 supported this directly without special coding.

Also, is this type of functionality needed for other Pipeline Stages
(other than XslTransform)?

Erik

Re: [Babeldoc-devel] Database Tables

[bruce <br...@mc...>]

On Friday 28 March 2003 09:28 am, ek...@ba... wrote:
> <<
> We add another configuration parameter to the XslTransform that provides
> the
> XSL document inline.  This will be in addition to the file configuration
> parameter.  So the logic is:
>
> 1.  If the file/url parameter is not null, load from the url
> 2.  if the inline parameter is not null, use the XSL in the parameter
>
>
> I'm not sure of the method signature that would take this, but is it
> possible to have an overloaded implementation that has one method that
> takes a URL and another that takes a String?

No, we have another configuration parameter for the XslTransform pipeline 
stage called, say transformationScript.  This contains the script inline

> Also, how would this information be stored in the Properties Files /
> CONFIG table?  An additional key/value pair or column?  Or are you
> thinking of using the existing key / cfg_value field to store EITHER the
> URL or the actual script?  If this is your choice, the db schema has to
> change to support more than 255 chars.

Bingo - we will have to increase the storage area.  The script will get stored 
in the cfg_value column.

> Otherwise, it sounds great!!!
>
> Erik
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Database Tables

[<ek...@ba...>]

<<
We add another configuration parameter to the XslTransform that provides
the
XSL document inline.  This will be in addition to the file configuration
parameter.  So the logic is:

1.  If the file/url parameter is not null, load from the url
2.  if the inline parameter is not null, use the XSL in the parameter
>>

I'm not sure of the method signature that would take this, but is it
possible to have an overloaded implementation that has one method that
takes a URL and another that takes a String?

Also, how would this information be stored in the Properties Files /
CONFIG table?  An additional key/value pair or column?  Or are you
thinking of using the existing key / cfg_value field to store EITHER the
URL or the actual script?  If this is your choice, the db schema has to
change to support more than 255 chars.

Otherwise, it sounds great!!!

Erik

Re: [Babeldoc-devel] Database Tables

[bruce <br...@mc...>]

Erik,

Comments inline...

On Friday 28 March 2003 08:54 am, ek...@ba... wrote:
> Sounds interesting and flexible but perhaps a little complicated.  I
> regret that I cannot immediately provide a more "elegant" solution, but
> I can tell you what was discussed at my database design meeting
> yesterday with our data architect ... please bear one thing in mind
> before reading on ... I'm tasked with delivering a very challenging
> system in a very short timeframe ... that being said, we have initially
> decided to add a Sybase "text" field (unlimited character length field)
> to the CONFIG table, named "cfg_script" that is nullable.  For rows in
> this table in which you would normally reference a file descriptor or
> URL in the cfg_value field, we will embed that script into "cfg_script"
> and read it in using SQLConfig.getConfig().  I will then have to figure
> out a way to feed this script (contained in a String) to the appropriate
> process (Xalan, etc) ... but I haven't even thought that far yet.

But this is where the real problem is, right here.  I think I might have an 
idea that will make things even simpler.

We add another configuration parameter to the XslTransform that provides the 
XSL document inline.  This will be in addition to the file configuration 
parameter.  So the logic is:  

1.  If the file/url parameter is not null, load from the url
2.  if the inline parameter is not null, use the XSL in the parameter

What do you think?

regards,
Bruce.


> Yes, your solution is MUCH more elegant than what I have detailed above,
> but I've got management coming down on me like a ton of bricks to get
> this project designed and developed.  I would much rather implement a
> solution that keeps me in-line with Babeldoc's progress.
>
> Thanks again for all your assistance and interest.
>
> Erik
>
> <<
> Erik,  Dejan:
>
> I think I have found a relatively simple solution:
>
> 1.  We implement a new URLStreamHandler so that we can have a new
> protocol
> (lets say, babelsql:) that can access the database just like a
> filesystem.
> 2.  We implement the virtual filesystem using three tables - a directory
> table
> that knows about about its parent directory and maintains an id.  A data
> table that knows about its directory table id and its own id and an
> "inode"
> table that tracks common stuff for the two tables: permissions, last
> write,
> access time, modification etc.
> 3.  Then we simply manage the data in the tables just like a regular
> filesystem and we access them in the same way.
>
> thoughts?
>
> regards,
> Bruce.
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Database Tables

[bruce <br...@mc...>]

Dejan

Yes, I have been looking over commons-vfs - and it looks to be a great 
project.  My only issue is that I want to get 1.0 out and the change of this 
fundamental portion of code is going to be (IMO) too many changes to 
fundamental code.

regards,
Bruce.

On Friday 28 March 2003 02:33 am, Dejan Krsmanovic wrote:
> Do you think it could be compatible with Commons VFS? I think it could be
> nice if we could use other VFS implementations...
>
> Dejan
>
> ----- Original Message -----
> From: "bruce" <br...@mc...>
> To: "Dejan Krsmanovic" <dej...@nb...>; "Babeldoc
> Developers List" <bab...@li...>
> Sent: Friday, March 28, 2003 3:11 AM
> Subject: Re: [Babeldoc-devel] Database Tables
>
> > Erik,  Dejan:
> >
> > I think I have found a relatively simple solution:
> >
> > 1.  We implement a new URLStreamHandler so that we can have a new
> > protocol (lets say, babelsql:) that can access the database just like a
> > filesystem. 2.  We implement the virtual filesystem using three tables -
> > a directory
>
> table
>
> > that knows about about its parent directory and maintains an id.  A data
> > table that knows about its directory table id and its own id and an
>
> "inode"
>
> > table that tracks common stuff for the two tables: permissions, last
>
> write,
>
> > access time, modification etc.
> > 3.  Then we simply manage the data in the tables just like a regular
> > filesystem and we access them in the same way.
> >
> > thoughts?
> >
> > regards,
> > Bruce.
> >
> > On Wednesday 26 March 2003 12:29 pm, bruce wrote:
> > > Dejan,
> > >
> > > This sounds just like what we need.   Let me look into it...
> > >
> > > regards,
> > > Bruce.
> > >
> > > On Wednesday 26 March 2003 11:34 am, Dejan Krsmanovic wrote:
> > > > Bruce, in future Babeldoc versions we should really think about using
> > > > Jakarta Commons VFS project. This component enables accessing data
>
> from
>
> > > > various sources. Currently local files, ftp files, WebDav, zip files
>
> and
>
> > > > some others are supported. They plan to include JDBC "file system" as
> > > > well. When you have a time check that project out. I think it could
> > > > be valuable in future...
> > > >
> > > > Dejan
> > > >
> > > > ----- Original Message -----
> > > > From: "bruce" <br...@mc...>
> > > > To: "Babeldoc Developers List" <bab...@li...>
> > > > Sent: Wednesday, March 26, 2003 3:18 PM
> > > > Subject: Re: [Babeldoc-devel] Database Tables
> > > >
> > > > > On Wednesday 26 March 2003 08:23 am, ek...@ba... wrote:
> > > > > > Well, I need both.  I need to store configuration information in
>
> the
>
> > > > > > database and I would like to store XSLT scripts (and everything
>
> else)
>
> > > > > > in the database also.
> > > > >
> > > > > The storing of the actual data in the database is the problem.  The
> > > > > XslTransform pipeline stage expects to be given a filename or URL
> > > > > of
>
> a
>
> > > > data
> > > >
> > > > > source which will contain the XSL data.  Now, if that is not to
> > > > > your
> > > >
> > > > liking,
> > > >
> > > > > then it will probably be necessary to implement either a general
> > > > > solution
> > > >
> > > > to
> > > >
> > > > > this (probably using a URL scheme) or a specific re-implementation
>
> of
>
> > > > > the pipeline stages to load from a database.
> > > > >
> > > > > > Good question though ... is the SQLConfig fully implemented /
>
> tested?
>
> > > > > It was working fine - about six months ago - you will have to do a
> > > > > little prototyping.  I certainly can help you with problems you may
> > > > > find.
> > > > >
> > > > > regards,
> > > > > Bruce.
> > > > >
> > > > > > -------------------------------------------------------
> > > > > > This SF.net email is sponsored by:
> > > > > > The Definitive IT and Networking Event. Be There!
> > > > > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > > > > _______________________________________________
> > > > > > Babeldoc-devel mailing list
> > > > > > Bab...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.net email is sponsored by:
> > > > > The Definitive IT and Networking Event. Be There!
> > > > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > > > _______________________________________________
> > > > > Babeldoc-devel mailing list
> > > > > Bab...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by:
> > > > The Definitive IT and Networking Event. Be There!
> > > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > > _______________________________________________
> > > > Babeldoc-devel mailing list
> > > > Bab...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > The Definitive IT and Networking Event. Be There!
> > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > _______________________________________________
> > > Babeldoc-devel mailing list
> > > Bab...@li...
> > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Database Tables

[<ek...@ba...>]

Sounds interesting and flexible but perhaps a little complicated.  I
regret that I cannot immediately provide a more "elegant" solution, but
I can tell you what was discussed at my database design meeting
yesterday with our data architect ... please bear one thing in mind
before reading on ... I'm tasked with delivering a very challenging
system in a very short timeframe ... that being said, we have initially
decided to add a Sybase "text" field (unlimited character length field)
to the CONFIG table, named "cfg_script" that is nullable.  For rows in
this table in which you would normally reference a file descriptor or
URL in the cfg_value field, we will embed that script into "cfg_script"
and read it in using SQLConfig.getConfig().  I will then have to figure
out a way to feed this script (contained in a String) to the appropriate
process (Xalan, etc) ... but I haven't even thought that far yet.

Yes, your solution is MUCH more elegant than what I have detailed above,
but I've got management coming down on me like a ton of bricks to get
this project designed and developed.  I would much rather implement a
solution that keeps me in-line with Babeldoc's progress.

Thanks again for all your assistance and interest.

Erik

<<
Erik,  Dejan:

I think I have found a relatively simple solution:

1.  We implement a new URLStreamHandler so that we can have a new
protocol
(lets say, babelsql:) that can access the database just like a
filesystem.
2.  We implement the virtual filesystem using three tables - a directory
table
that knows about about its parent directory and maintains an id.  A data
table that knows about its directory table id and its own id and an
"inode"
table that tracks common stuff for the two tables: permissions, last
write,
access time, modification etc.
3.  Then we simply manage the data in the tables just like a regular
filesystem and we access them in the same way.

thoughts?

regards,
Bruce.
>>

Re: [Babeldoc-devel] A few more questions

[<ek...@ba...>]

<<
Do you plan to release this project as open source? If you have such
plans
can you describe more what exactly are you planning to implement. Maybe
we
(company that I work for) will need something similar  so I could help
you
with these.
How do you plan to "put" documents into pipeline? By some web UI or
using
scanners or something else?
>>

The project is for use internally within my company (The Bank of NY).
Rather than rebuilding "the wheel" from scratch, I discovered that
Babeldoc's core engine did most of what I needed.  I was planning to
"build around" Babeldoc for the additional functionality that we needed
while having as small an impact on "code modification" within Babeldoc
as possible.  Of course, if I find a good reason to improve/extend
Babeldoc, I shall (according to Babeldoc standards) and will offer it to
the open source community (i.e. you guys) for inclusion if you choose to
-- I've been starting to think about a Pipeline Stage for talking to
EJBs using Rhino or Jython, for example, since this is one of my needs.

The current plan is for us to feed the pipeline directly using
com.babeldoc.call.command.PipelineFeeder.process() method from a
Message-Driven Bean that runs on Weblogic Server v6.1 and is triggered
by a JMS message that is dropped on a Weblogic JMS Queue.  We will also
have an adminstrative user interface that will permit someone to create
or update a pipeline and its stages (including its config key/value
pairs) interactively where it will be persisted to our Sybase 12.5
database.  The system will run in a clustered Weblogic environment on a
Solaris platform.

The purpose of the project is to accept "Alert Messages" in XML format,
derive additional information from "Resource systems" (which can be
implemented as Stored Procedures, EJBs, Web Services, etc.), combine the
XML input message with the derived additional information (most likely
using XSLT), and send the resultant information to one or more Recipient
Systems (which can be implemented as EJBs, Web Services, JMS Queues,
etc).  The problem we have is that during development of this system, we
cannot code in Java for any of the following:
1. The Source systems that will send us XML
2. The Resource systems that will provide us with additional information
3. The Recipient systems that will receive the finished information

This is because we will be getting requests constantly within the
company for new "Alert Messages" and we cannot be deploying new code to
our environment for every request (due to rigourous testing, data center
standards, etc).  Therefore, the only way for us to "deploy code" is via
interpretive-language code that is placed in the database (i.e. XSLT
scripts, JavaScripts, Jython Scripts).  It must be in the database
because our clustered environment means that files written to the "file
system" on one box will not be available to instances of our servers on
other boxes.  We cannot share mounted disk devices between systems.
Additionally, the operations folks frown upon us writing to the file
system a lot, as does the EJB standard.

That is the unabridged description ... I bet you're sorry you asked,
right???

Erik

Re: [Babeldoc-devel] A few more questions

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

> My problem is that I will have users using an administrative UI to
> add/update pipeline stages.  They should only be working on one pipeline
> at a time.  They will have the flexibility to change the pipeline stage
> names and add pipeline stage names ... I do not want them to be
> responsible for correctly typing the pipeline name and a period (".") to
> prepend the pipeline stage name.  Additionally, when modifying, I would
> prefer not to have to strip off this information for presentation to the
> user only to have to put it back on when updating the database.

Do you plan to release this project as open source? If you have such plans
can you describe more what exactly are you planning to implement. Maybe we
(company that I work for) will need something similar  so I could help you
with these.
How do you plan to "put" documents into pipeline? By some web UI or using
scanners or something else?

Dejan

Re: [Babeldoc-devel] Database Tables

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

Do you think it could be compatible with Commons VFS? I think it could be
nice if we could use other VFS implementations...

Dejan

----- Original Message -----
From: "bruce" <br...@mc...>
To: "Dejan Krsmanovic" <dej...@nb...>; "Babeldoc
Developers List" <bab...@li...>
Sent: Friday, March 28, 2003 3:11 AM
Subject: Re: [Babeldoc-devel] Database Tables


> Erik,  Dejan:
>
> I think I have found a relatively simple solution:
>
> 1.  We implement a new URLStreamHandler so that we can have a new protocol
> (lets say, babelsql:) that can access the database just like a filesystem.
> 2.  We implement the virtual filesystem using three tables - a directory
table
> that knows about about its parent directory and maintains an id.  A data
> table that knows about its directory table id and its own id and an
"inode"
> table that tracks common stuff for the two tables: permissions, last
write,
> access time, modification etc.
> 3.  Then we simply manage the data in the tables just like a regular
> filesystem and we access them in the same way.
>
> thoughts?
>
> regards,
> Bruce.
>
> On Wednesday 26 March 2003 12:29 pm, bruce wrote:
> > Dejan,
> >
> > This sounds just like what we need.   Let me look into it...
> >
> > regards,
> > Bruce.
> >
> > On Wednesday 26 March 2003 11:34 am, Dejan Krsmanovic wrote:
> > > Bruce, in future Babeldoc versions we should really think about using
> > > Jakarta Commons VFS project. This component enables accessing data
from
> > > various sources. Currently local files, ftp files, WebDav, zip files
and
> > > some others are supported. They plan to include JDBC "file system" as
> > > well. When you have a time check that project out. I think it could be
> > > valuable in future...
> > >
> > > Dejan
> > >
> > > ----- Original Message -----
> > > From: "bruce" <br...@mc...>
> > > To: "Babeldoc Developers List" <bab...@li...>
> > > Sent: Wednesday, March 26, 2003 3:18 PM
> > > Subject: Re: [Babeldoc-devel] Database Tables
> > >
> > > > On Wednesday 26 March 2003 08:23 am, ek...@ba... wrote:
> > > > > Well, I need both.  I need to store configuration information in
the
> > > > > database and I would like to store XSLT scripts (and everything
else)
> > > > > in the database also.
> > > >
> > > > The storing of the actual data in the database is the problem.  The
> > > > XslTransform pipeline stage expects to be given a filename or URL of
a
> > >
> > > data
> > >
> > > > source which will contain the XSL data.  Now, if that is not to your
> > >
> > > liking,
> > >
> > > > then it will probably be necessary to implement either a general
> > > > solution
> > >
> > > to
> > >
> > > > this (probably using a URL scheme) or a specific re-implementation
of
> > > > the pipeline stages to load from a database.
> > > >
> > > > > Good question though ... is the SQLConfig fully implemented /
tested?
> > > >
> > > > It was working fine - about six months ago - you will have to do a
> > > > little prototyping.  I certainly can help you with problems you may
> > > > find.
> > > >
> > > > regards,
> > > > Bruce.
> > > >
> > > > > -------------------------------------------------------
> > > > > This SF.net email is sponsored by:
> > > > > The Definitive IT and Networking Event. Be There!
> > > > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > > > _______________________________________________
> > > > > Babeldoc-devel mailing list
> > > > > Bab...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by:
> > > > The Definitive IT and Networking Event. Be There!
> > > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > > _______________________________________________
> > > > Babeldoc-devel mailing list
> > > > Bab...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > The Definitive IT and Networking Event. Be There!
> > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > _______________________________________________
> > > Babeldoc-devel mailing list
> > > Bab...@li...
> > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Database Tables

[bruce <br...@mc...>]

Erik,  Dejan:

I think I have found a relatively simple solution:

1.  We implement a new URLStreamHandler so that we can have a new protocol 
(lets say, babelsql:) that can access the database just like a filesystem.
2.  We implement the virtual filesystem using three tables - a directory table 
that knows about about its parent directory and maintains an id.  A data 
table that knows about its directory table id and its own id and an "inode" 
table that tracks common stuff for the two tables: permissions, last write, 
access time, modification etc.
3.  Then we simply manage the data in the tables just like a regular 
filesystem and we access them in the same way.

thoughts?

regards,
Bruce.

On Wednesday 26 March 2003 12:29 pm, bruce wrote:
> Dejan,
>
> This sounds just like what we need.   Let me look into it...
>
> regards,
> Bruce.
>
> On Wednesday 26 March 2003 11:34 am, Dejan Krsmanovic wrote:
> > Bruce, in future Babeldoc versions we should really think about using
> > Jakarta Commons VFS project. This component enables accessing data from
> > various sources. Currently local files, ftp files, WebDav, zip files and
> > some others are supported. They plan to include JDBC "file system" as
> > well. When you have a time check that project out. I think it could be
> > valuable in future...
> >
> > Dejan
> >
> > ----- Original Message -----
> > From: "bruce" <br...@mc...>
> > To: "Babeldoc Developers List" <bab...@li...>
> > Sent: Wednesday, March 26, 2003 3:18 PM
> > Subject: Re: [Babeldoc-devel] Database Tables
> >
> > > On Wednesday 26 March 2003 08:23 am, ek...@ba... wrote:
> > > > Well, I need both.  I need to store configuration information in the
> > > > database and I would like to store XSLT scripts (and everything else)
> > > > in the database also.
> > >
> > > The storing of the actual data in the database is the problem.  The
> > > XslTransform pipeline stage expects to be given a filename or URL of a
> >
> > data
> >
> > > source which will contain the XSL data.  Now, if that is not to your
> >
> > liking,
> >
> > > then it will probably be necessary to implement either a general
> > > solution
> >
> > to
> >
> > > this (probably using a URL scheme) or a specific re-implementation of
> > > the pipeline stages to load from a database.
> > >
> > > > Good question though ... is the SQLConfig fully implemented / tested?
> > >
> > > It was working fine - about six months ago - you will have to do a
> > > little prototyping.  I certainly can help you with problems you may
> > > find.
> > >
> > > regards,
> > > Bruce.
> > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by:
> > > > The Definitive IT and Networking Event. Be There!
> > > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > > _______________________________________________
> > > > Babeldoc-devel mailing list
> > > > Bab...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > The Definitive IT and Networking Event. Be There!
> > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > _______________________________________________
> > > Babeldoc-devel mailing list
> > > Bab...@li...
> > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] A few more questions

[<ek...@ba...>]

It was right in front of me.  Sorry.  Am I to assume that the "name"
argument used in SqlConfigService.getConfig() represents the
PipelineName?  I was under the assumption that it represented the
ConfigName.  My mistake.  Sorry.

As an "interesting" side-effect, this method calls SqlConfig.setString()
to set the configuration information into the SqlConfig.HashMap but also
calls back to SqlConfigService.setString(), which subsequently deletes
the row just read and re-inserts it into the database.

I understand this is generic code and that SqlConfig.setString() could
be called from other places ... not just when read from the db ... I may
want to "optimize" this a little when I modify the implementation to use
Pipeline Name as well.

Erik


<<
Take a look at the getConfig method on
com.babeldoc.sql.config.SqlConfigService - this basically selects all
the
config options from which starts with 'config name' and then places them
in a
ConfigObject.
>>

Re: [Babeldoc-devel] A few more questions

[bruce <br...@mc...>]

Take a look at the getConfig method on 
com.babeldoc.sql.config.SqlConfigService - this basically selects all the 
config options from which starts with 'config name' and then places them in a 
ConfigObject.



On Thursday 27 March 2003 11:32 am, ek...@ba... wrote:
> No problem.  Where can I find the code that does the PipelineName + "."
> + ConfigName concatenation for the SQLConfigService?
>
> <<
> Ultimately this is your choice - you are the one to do the work here and
> so
> you do the change.  I just wanted to state my preference - bearing in
> mind
> that I have not used the SqlConfigService in production nor anticipate
> doing
> so in the near future.
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] Scanners and filters

[bruce <br...@mc...>]

Dejan,

On Thursday 27 March 2003 11:19 am, Dejan Krsmanovic wrote:
> Bruce, I am working on implementation of  regular expression filtering in
> scanners. Since I have no better idea there will be config options in each
> scanners where filtering have sence. So in directory and ftp scanners
> messages could be filtered by filename, and in case of mailbox scanner
> subject and body (and maybe fromAddress) could be filtered. I will probably
> drop code for include and exclude filters from dir scanners since they
> could be used only for extensions not filename. Is it OK to delete it?

Your call - you know the code.

> Also, I think one filter per field is enough since you can express anything
> you want in regular expressions (no need for some kind of include and
> exclude filters for every field...).

Yes - more than one expression is fine for now.

> By the way, I will implement methods which deals with regular expression in
> ScannerWorker class. Currently I use JDK 1.4 java.util.regex.* package but
> we can later change this and use something that would work on older JDK
> versions (Jakarta RegEx or ORO). It will be easy since there are only two
> methods..

I dont know much about the jdk1.4 regex package.  I do know that the ORO 
package is highly regarded.

> I have also added 'format' config option in SmtpWriter, which can be used
> to specify if message is in html or plain text. Default is plain of
> course...
>
> Dejan
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] A few more questions

[<ek...@ba...>]

No problem.  Where can I find the code that does the PipelineName + "."
+ ConfigName concatenation for the SQLConfigService?

<<
Ultimately this is your choice - you are the one to do the work here and
so
you do the change.  I just wanted to state my preference - bearing in
mind
that I have not used the SqlConfigService in production nor anticipate
doing
so in the near future.
>>

Re: [Babeldoc-devel] A few more questions

[bruce <br...@mc...>]

Erik,

Ultimately this is your choice - you are the one to do the work here and so 
you do the change.  I just wanted to state my preference - bearing in mind 
that I have not used the SqlConfigService in production nor anticipate doing 
so in the near future.

regards,
Bruce.
On Thursday 27 March 2003 11:18 am, ek...@ba... wrote:
> Bruce, I respect your suggestion to not overcomplicate the matter.
> Perhaps you can make a different suggestion then.
>
> My problem is that I will have users using an administrative UI to
> add/update pipeline stages.  They should only be working on one pipeline
> at a time.  They will have the flexibility to change the pipeline stage
> names and add pipeline stage names ... I do not want them to be
> responsible for correctly typing the pipeline name and a period (".") to
> prepend the pipeline stage name.  Additionally, when modifying, I would
> prefer not to have to strip off this information for presentation to the
> user only to have to put it back on when updating the database.
>
> Additionally, if my DBA found out about the concatenation, she would
> have a cow ... but she doesn't have to know every detail.  It might also
> be frowned upon during my peer review.

Re: [Babeldoc-devel] Scanners and filters

[<ek...@ba...>]

It appears that my Weblogic Server's reliance on JDK 1.3.1 is becoming a
problem that I will have to manage.

<<
Bruce, I am working on implementation of  regular expression filtering
in
scanners. Since I have no better idea there will be config options in
each
scanners where filtering have sence. So in directory and ftp scanners
messages could be filtered by filename, and in case of mailbox scanner
subject and body (and maybe fromAddress) could be filtered. I will
probably
drop code for include and exclude filters from dir scanners since they
could
be used only for extensions not filename. Is it OK to delete it?
Also, I think one filter per field is enough since you can express
anything
you want in regular expressions (no need for some kind of include and
exclude filters for every field...).
By the way, I will implement methods which deals with regular expression
in
ScannerWorker class. Currently I use JDK 1.4 java.util.regex.* package
but
we can later change this and use something that would work on older JDK
versions (Jakarta RegEx or ORO). It will be easy since there are only
two
methods..

I have also added 'format' config option in SmtpWriter, which can be
used to
specify if message is in html or plain text. Default is plain of
course...

Dejan
>>

[Babeldoc-devel] Scanners and filters

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

Bruce, I am working on implementation of  regular expression filtering in
scanners. Since I have no better idea there will be config options in each
scanners where filtering have sence. So in directory and ftp scanners
messages could be filtered by filename, and in case of mailbox scanner
subject and body (and maybe fromAddress) could be filtered. I will probably
drop code for include and exclude filters from dir scanners since they could
be used only for extensions not filename. Is it OK to delete it?
Also, I think one filter per field is enough since you can express anything
you want in regular expressions (no need for some kind of include and
exclude filters for every field...).
By the way, I will implement methods which deals with regular expression in
ScannerWorker class. Currently I use JDK 1.4 java.util.regex.* package but
we can later change this and use something that would work on older JDK
versions (Jakarta RegEx or ORO). It will be easy since there are only two
methods..

I have also added 'format' config option in SmtpWriter, which can be used to
specify if message is in html or plain text. Default is plain of course...

Dejan

Re: [Babeldoc-devel] A few more questions

[<ek...@ba...>]

Bruce, I respect your suggestion to not overcomplicate the matter.
Perhaps you can make a different suggestion then.

My problem is that I will have users using an administrative UI to
add/update pipeline stages.  They should only be working on one pipeline
at a time.  They will have the flexibility to change the pipeline stage
names and add pipeline stage names ... I do not want them to be
responsible for correctly typing the pipeline name and a period (".") to
prepend the pipeline stage name.  Additionally, when modifying, I would
prefer not to have to strip off this information for presentation to the
user only to have to put it back on when updating the database.

Additionally, if my DBA found out about the concatenation, she would
have a cow ... but she doesn't have to know every detail.  It might also
be frowned upon during my peer review.

Where can I find the code that concatenates the two together so I can
better understand the impact?

Erik


<<
Yeah, right :)

On the SQL config thing - think long and hard about making it a joined
table
solution - think Occams razor here.
>>

On Thursday 27 March 2003 11:03 am, ek...@ba... wrote:
> HOLY SMOKE!  You work fast!!
>
> And I assume the JUnit tests were updated and executed within this
short
> timeframe too, right??  ;-)
>
> Thanks again for your help.  GREATLY Appreciated.
>
> Erik

[Babeldoc-devel] Concatenating PipelineName and ConfigName

[<ek...@ba...>]

Where would I find the code that concatenates these together as I am
told they are for the SQLConfigService?  I see the setString( ) method
on SQLConfig and SQLConfigService take "name" as an argument and I am
told this is the concatentation of PipelineName + "." + ConfigName.
Where is the concatenation done?
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.

Re: [Babeldoc-devel] A few more questions

[bruce <br...@mc...>]

Yeah, right :)

On the SQL config thing - think long and hard about making it a joined table 
solution - think Occams razor here.

On Thursday 27 March 2003 11:03 am, ek...@ba... wrote:
> HOLY SMOKE!  You work fast!!
>
> And I assume the JUnit tests were updated and executed within this short
> timeframe too, right??  ;-)
>
> Thanks again for your help.  GREATLY Appreciated.
>
> Erik
>
>
>
>
>
> bruce <br...@mc...>@lists.sourceforge.net on 03/27/2003
> 10:53:24 AM
>
> Sent by:    bab...@li...
>
>
> To:    ek...@ba..., "Babeldoc Developers List"
>        <bab...@li...>
> cc:
> Subject:    Re: [Babeldoc-devel] A few more questions
>
>
> Its done,  update com.babeldoc.core.config.ConfigService
>
> On Thursday 27 March 2003 10:49 am, bruce wrote:
> > Actually
> >
> > Its even simpler than that.  The configuration information is actually
> > cached at the ConfigService - I will add a static to that to nuke the
> > caches.
> >
> > On Thursday 27 March 2003 10:43 am, ek...@ba... wrote:
> > > <<
> > > Maybe it is better idea to have such method in IConfigService too.
>
> Why
>
> > > not
> > > have option to reload configuration from properties files too?
> > >
> > >
> > > Sounds like a reasonable request.  Initially, I will implement it in
> > > SQLConfigService to get my solution working and then I will look
>
> into
>
> > > the effort (which I imagine is quite small) to implement it in the
>
> other
>
> > > classes that implement IConfigService.
> > >
> > > ... unless someone objects ...
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > The Definitive IT and Networking Event. Be There!
> > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > _______________________________________________
> > > Babeldoc-devel mailing list
> > > Bab...@li...
> > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] A few more questions

[<ek...@ba...>]

HOLY SMOKE!  You work fast!!

And I assume the JUnit tests were updated and executed within this short
timeframe too, right??  ;-)

Thanks again for your help.  GREATLY Appreciated.

Erik





bruce <br...@mc...>@lists.sourceforge.net on 03/27/2003
10:53:24 AM

Sent by:    bab...@li...


To:    ek...@ba..., "Babeldoc Developers List"
       <bab...@li...>
cc:
Subject:    Re: [Babeldoc-devel] A few more questions


Its done,  update com.babeldoc.core.config.ConfigService

On Thursday 27 March 2003 10:49 am, bruce wrote:
> Actually
>
> Its even simpler than that.  The configuration information is actually
> cached at the ConfigService - I will add a static to that to nuke the
> caches.
>
> On Thursday 27 March 2003 10:43 am, ek...@ba... wrote:
> > <<
> > Maybe it is better idea to have such method in IConfigService too.
Why
> > not
> > have option to reload configuration from properties files too?
> >
> >
> > Sounds like a reasonable request.  Initially, I will implement it in
> > SQLConfigService to get my solution working and then I will look
into
> > the effort (which I imagine is quite small) to implement it in the
other
> > classes that implement IConfigService.
> >
> > ... unless someone objects ...
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Babeldoc-devel mailing list
Bab...@li...
https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] A few more questions

[bruce <br...@mc...>]

You got it exactly Dejan.

Actually all it does is:

configs.clear();

Quite simple really...

On Thursday 27 March 2003 10:55 am, Dejan Krsmanovic wrote:
> It seems to me that this method should be implemented in ConfigService
> class (no need for implementing it in subclasses). This is
> getConfigMethod() public IConfig getConfig(String name) {
>
> //System.out.println("Getting config: "+name);
>
> IConfig config = (IConfig) configs.get(name);
>
> if (config == null) {
>
> //System.out.println("Config: "+name+" not found, loading.");
>
> config = configService.getConfig(name);
>
> configs.put(name, config);
>
> }
>
> return config;
>
> }
>
> All you need is to set configs Map to new, empty Map. Something like
> public void reset() {
>
>     configs = Collections.synchronizedMap(new LRUMap(lruNum));
>
> }
>
> Am I right, Bruce?
>
> Dejan
> ----- Original Message -----
> From: <ek...@ba...>
> To: "Babeldoc Developers List" <bab...@li...>
> Sent: Thursday, March 27, 2003 4:43 PM
> Subject: Re: [Babeldoc-devel] A few more questions
>
> > <<
> > Maybe it is better idea to have such method in IConfigService too. Why
> > not
> > have option to reload configuration from properties files too?
> >
> >
> > Sounds like a reasonable request.  Initially, I will implement it in
> > SQLConfigService to get my solution working and then I will look into
> > the effort (which I imagine is quite small) to implement it in the other
> > classes that implement IConfigService.
> >
> > ... unless someone objects ...
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] A few more questions

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

OK. I see you have already done it...

Dejan

----- Original Message -----
From: "bruce" <br...@mc...>
To: <ek...@ba...>; "Babeldoc Developers List"
<bab...@li...>
Sent: Thursday, March 27, 2003 4:53 PM
Subject: Re: [Babeldoc-devel] A few more questions


> Its done,  update com.babeldoc.core.config.ConfigService
>
> On Thursday 27 March 2003 10:49 am, bruce wrote:
> > Actually
> >
> > Its even simpler than that.  The configuration information is actually
> > cached at the ConfigService - I will add a static to that to nuke the
> > caches.
> >
> > On Thursday 27 March 2003 10:43 am, ek...@ba... wrote:
> > > <<
> > > Maybe it is better idea to have such method in IConfigService too. Why
> > > not
> > > have option to reload configuration from properties files too?
> > >
> > >
> > > Sounds like a reasonable request.  Initially, I will implement it in
> > > SQLConfigService to get my solution working and then I will look into
> > > the effort (which I imagine is quite small) to implement it in the
other
> > > classes that implement IConfigService.
> > >
> > > ... unless someone objects ...
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by:
> > > The Definitive IT and Networking Event. Be There!
> > > NetWorld+Interop Las Vegas 2003 -- Register today!
> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > > _______________________________________________
> > > Babeldoc-devel mailing list
> > > Bab...@li...
> > > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] A few more questions

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

It seems to me that this method should be implemented in ConfigService class
(no need for implementing it in subclasses). This is getConfigMethod()
public IConfig getConfig(String name) {

//System.out.println("Getting config: "+name);

IConfig config = (IConfig) configs.get(name);

if (config == null) {

//System.out.println("Config: "+name+" not found, loading.");

config = configService.getConfig(name);

configs.put(name, config);

}

return config;

}

All you need is to set configs Map to new, empty Map. Something like
public void reset() {

    configs = Collections.synchronizedMap(new LRUMap(lruNum));

}

Am I right, Bruce?

Dejan
----- Original Message -----
From: <ek...@ba...>
To: "Babeldoc Developers List" <bab...@li...>
Sent: Thursday, March 27, 2003 4:43 PM
Subject: Re: [Babeldoc-devel] A few more questions


>
> <<
> Maybe it is better idea to have such method in IConfigService too. Why
> not
> have option to reload configuration from properties files too?
> >>
>
> Sounds like a reasonable request.  Initially, I will implement it in
> SQLConfigService to get my solution working and then I will look into
> the effort (which I imagine is quite small) to implement it in the other
> classes that implement IConfigService.
>
> ... unless someone objects ...
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel

Re: [Babeldoc-devel] A few more questions

[bruce <br...@mc...>]

Its done,  update com.babeldoc.core.config.ConfigService

On Thursday 27 March 2003 10:49 am, bruce wrote:
> Actually
>
> Its even simpler than that.  The configuration information is actually
> cached at the ConfigService - I will add a static to that to nuke the
> caches.
>
> On Thursday 27 March 2003 10:43 am, ek...@ba... wrote:
> > <<
> > Maybe it is better idea to have such method in IConfigService too. Why
> > not
> > have option to reload configuration from properties files too?
> >
> >
> > Sounds like a reasonable request.  Initially, I will implement it in
> > SQLConfigService to get my solution working and then I will look into
> > the effort (which I imagine is quite small) to implement it in the other
> > classes that implement IConfigService.
> >
> > ... unless someone objects ...
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:
> > The Definitive IT and Networking Event. Be There!
> > NetWorld+Interop Las Vegas 2003 -- Register today!
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> > _______________________________________________
> > Babeldoc-devel mailing list
> > Bab...@li...
> > https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel