Re: Beagle roadmap.

[msevior physics unimelb edu au]

> On Wed, 2004-10-06 at 18:55 +1000, Martin Sevior wrote:
>
>> The C-functions take care of all the stuff about making sure the remote
>> abiword is running, setting up the communication pipes,
>> cleaning up afterward.
>>
>> A new abiword is not spawned on every document. We reuse the currently
>> running one until it crashes or when you do a finalizeConversions call.
>> If the remote AbiWord crashes a new one is spawned.
>>
>
> Sounds nice.  However, according to your suggestion,
>
> 	* for beagle to index word processor documents, *AbiWord* should exist
> and this creates a dependency on Beagle and in turn on users to install
> AbiWord, which is not *OK*.
>
> In general, Beagle should be independent and should not impose any hard-
> restrictions on user that he should install a particular application for
> beagle to work.
>
> Jon, what is your opinion on this?
>

Well I can see your point about reducing dependencies. Everybody wants to
do this. However you already have the enormous mono dependency which for
various reasons has a hard time getting distributed in important mainline
distos. AbiWord is already on these distros.

My impression from Nat's email was he didn't really care about this.

>> The advantage of doing things this way is:
>>
>> 1. We AbiWord developers don't have to maintain a separate library just
>> for Beagle. As the filters for Abiword are improved in the continuous
>> Open source way, Beagle gets them too.
>>
> AbiWord developers don't have to maintain a library just for beagle,
> rather, it will be handy for AbiWord developers, if, their *filter* code
> exists as a library.  Whoever wants to contribute to "filters" have to
> just modify the library and not the core AbiWord.  Thus making life
> easier for AbiWord developers and other opensource hackers.
>

Well actually a lot of our filters are in plugins and there is a project
called AbiConvert which basically uses these plus our built-in filters to
convert various document formats (well mostly MS Word) to RTF. I imagine
it wouldn't be too hard to make it spit out SWX instead.

It wouldn't be hard to make all our filters plugins. We will just make
sure they are distributed in our rpms.

Then you'd to rewrite the document model or somehow incorporate AbiConvert
into your framework.

Hold it, I'm confused here. Can you incorporate C and C++ libaries into
the C# framework or will everything have to be written in C#?

Having said all this I'm not particularly keen to do this work myself. I
have more than enough to do with AbiWord as general purpose wordprocessor.
On the other hand abi devels have expressed a desire to librarize the
program. If you're keen on pursing this we can start a discussion on the
abiword-devel list and see what people think and if you can find
like-minded devels to help you.

> Moreover, fixes for filters just modify the library and no changes to
> the AbiWord... doesn't that sound nice???!!!!
>

Well the processes isn't quite that independent. Various formats,
particularly RTF, have required modifications to our document model
interface to import. This happens because many document models don't match
nicely to AbiWords and we have to work around them. In addition as we
expand AbiWord's capabilities we improve the filters to take advantage of
this.

Also we're continously tweaking them as we find weaknesses in their
interface to the AbiWord document model and as we discover issues with
both our document model and layout classes.

>> 2. You don't have to write a filter for every WP format under the sun.
>> Just improve the ones we already have. (Which generally happens in the
>> continuous open-source way anyway.)
>>
> Obviously, we are not going to write filters for every WP format other
> than what we have in our Filters list now.
>

Well I guess my point is that these filters exist right now. They're there
waiting to be used. Why not use them?

> Given that, I also want to make sure that the Beagle back-end (filters)
> will be expanded to support every other WP formats. (maybe Ph-III).
>
> It will be a nice project for someone to make an independent library of
> filters from AbiWord or OO.o.
>

Ah another "someone". Someone is a very busy fellow :-) I have lots of
projects for someone to do too.

Having said that, the wv and libwpd libraries are good examples of what
can be achieved. libwpd was developed by AbiWord developers who also wrote
a swx backend for use by OO.o.

If you like an alternative to get started is to take these two libraries
hook up code to their various callbacks and make sense of the output.
I guess in the case of the libwpd you could just use the swx generator
directly.

>> 4. There is very little performance penalty for doing things this way.
>> The process of filling the AbiWord document model is far faster
>> than building a view. All you need to do is pass a filename then
>> read the resulting text file.
>>
> As I said earlier, beagle doesn't want just a *stream of text*...
> something bit more... attributes of text like bold, italic, section
> head, chapter head, etc.
>

No problem, we'll output into swx if you prefer although the swx exporter
hasn't been extensively developed as yet.

Finally if you want to take document image snapshots, you do need a full
blown Word Processor. I just realized that with the new svg backend
to gnome-print it would trivial to generate an svg image of the front page
of every document.

I still think having an out-of-process convertor for these filters makes
sense. You gain a lot of fault tolerence that way.

Cheers,

Martin

> Cheers,
>
> V. Varadhan.
>
>