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

List:       kde-core-devel
Subject:    Re: KParts API: thinking about the future (patch)
From:       David Faure <david () mandrakesoft ! com>
Date:       2002-03-04 0:02:55
[Download RAW message or body]

On Monday 04 March 2002 00:50, Waldo Bastian wrote:
> On Sunday 03 March 2002 01:39 pm, David Faure wrote:
> > On Sunday 03 March 2002 22:17, Martijn Klingens wrote:
> > > public:
> > >   bool openStream() { return doOpenStream(); }
> > >   bool writeStream( const QDataStream &s ) { return doWriteStream( s ); }
> >
> > [Note: I meant QByteArray here. Whoops.]
> 
> Ah.. I already started to wonder :-)
> 
> Thinking about your problems with multipart support.... another approach could 
> be to use internal IO-slaves. E.g. you would pass a URL that points to an 
> internal IO-slave and the part would then ask for that URL and get's it data 
> from this io-slave. I must say your solution is more elegant but the 
> drawbacks would be that the KPart(s) need to be adapted to it. You will never 
> be able to rely on all parts having support for this stream extension.

Right. But for full "server push" support we need the parts to be adapted anyway,
so that they are able to render the data progressively.
For instance if one uses katepart with an internal (or external) ioslave that never 
terminates sending data.... nothing will ever show up. I think the API above makes
it more explicit what is expected from the part.

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 ;)

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://people.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

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