On Mon, 4 Mar 2002, David Faure wrote:
> The solution of internal-IO-slaves is nice too though, for sure. No change in API,
> no change in the part, and many new possibilities offered.
> And indeed if the parts are made to support progressive loading, then there is
> no more need for the streaming API in KParts. Now I'm undecided ;)

Well, both in your multipart case and in my case it is absolutely required
that the part supports streaming. So we have to make completely sure from
the hosting application that we only load parts that support streaming /
progressive loading.

Using the existing KParts interface with internal KIO slaves does not
automatically guarantuee that this is the case for each and every KPart
that can is and will be written.

Since internal slaves have their own advantages I'm not really opposed to
them, but then we definitely need a method in the KParts API to signal
whether the part supports progressive loading, something like

virtual bool canLoadProgresive();

or so. Perferably also in the .desktop files so we can ask the trader for
parts that support this extension only.

And that's about as far as my knowledge goes, I think David and Waldo
should now come up with the final implementation ;-)

Martijn