[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: RFC: Optimizing the Filter API
From:       David Faure <faure () kde ! org>
Date:       2000-02-24 22:59:59
[Download RAW message or body]

On Thu, Feb 24, 2000 at 10:05:43PM +0100, Werner Trobin wrote:
> Hi!
> 
> As Matthias Elter asked for a filter which is efficient enough
> to handle large amounts of data (TIFF images and so on) I
> thought about changing the API and streamlining the process of
> converting.
> 
> Therefore I suggest the following changes:
> 
> 1) Change the KoFilter class (and due to that all the filters)
>    to write (file import) or read (file export) a QDomDocument
>    (and not a file as it is now). This QDomDocument is passed
>    to the filter in the filter() Method. This is no problem
>    since all (non trivial) filters but one (KWord's HTML filter)
>    write/read QDomDocuments. For the import filters which use plain
>    QStrings I suggest using the setContent() method of
>    QDomDocument. This is a small performance hit for that filter
>    (KWord HTML filter), but it should increase the general
>    performance. Export filters can also easily be rewritten that
>    we can use QDomDocument from now on.
> 
> 2) We have to add a pointer-to-QDomDocument-paramenter with 0L
>    as default value to KoFilterManager::import() and
>    KoFilterManager::prepareExport(). This QDomDocument is the
>    one which is passed on to the filter in case it is available.
>    The filter writes/reads this file and we don't have to write
>    it to a file/read it from a file.
>    It there is no QDomDocument (e.g. KWord will surely not use
>    QDom in the next time), KoFilterManager creates its own
>    QDomDocument and passes that one to the filters. In this case
>    it converts the QDomDocument to a file after filtering. This
>    solution guarantees compatibility with the KOML-using-stuff.
> 
> 3) We have to add a method to KoDocument which provides such a
>    empty QDomDocument for loading/saving. The default
>    implementation returns 0L (i.e. old technology) and if you
>    want to use a streamlined filter you have to reimplement that
>    method.
>    Another possibility would be to do it the other way (i.e. the
>    default impl. returns a QDomDocument), but I'm not sure about
>    that.
> 
> 
> I think this is not the silver bullet(tm), but as some parts are
> using the KOML library and some are using QDom we have to support
> both possibilities...
> 
> Please tell me what you think of it - I'll implement it ASAP :)

Looks great !

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]