[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:       Holger Freyther <freyther () gmx ! net>
Date:       2002-03-05 16:01:15
[Download RAW message or body]

Am Monday 04 March 2002 01:02 schrieb David Faure:
> 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 ;)

I'm for your initial API changes. Their much cleaner and you can find out if a 
part supports streaming without .desktop adjustments. If openStream() fails 
you know for sure a part doesn't support it.

Another thought is what happends if a part supports say two different types of 
data. For one it supports streaming and for the other not.
Wouldn't a virtual bool openStream( const QString &mimeType = QString::null ){ 
return false; ); better?


Just my 0.02 Euro

Holger 'zecke' Freyther

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