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

List:       kfm-devel
Subject:    Re: Swfdec/Konqi integration
From:       "koos vriezen" <koos.vriezen () gmail ! com>
Date:       2007-06-18 18:42:25
Message-ID: d4e708d60706181142l3e64fc9cs8644a7cf148b8102 () mail ! gmail ! com
[Download RAW message or body]

2007/6/18, Thiago Macieira <thiago@kde.org>:
>
> koos vriezen said:
> > Thanks. I hope you noticed it's more an ad-hoc interface now. Like you
> > indeed noticed the 'getUrlNotify' and also 'finish' are odd and based
> > on the fact that there is currently only one active stream. And
> > streams are worked out sequentially.
> > This should be changed to something like
> > 'requestStream(streamid)'/destroyStream(streamid) for the plugin and
> > streamDone from the browser side kpart.
>
> No, there shouldn't.
>
> Just use different object paths. There's absolutely no need to stick IDs
> into the API when you can use objects to do the same. One object (path) =
> one stream.

Good point, didn't think of that

> > Also the to stdin streaming
> > should be send in chunks containing a header of its size and streamid.
>
> "streamid" being an object path.
>
> > Data must be retrieved from the browser side for eg. auth. reasons,
> > though ideally I would like to stream directly from kioslaves of
> > course. Nevertheless, it's the xserver that uses most of the CPU w/
> > flash movies.
>
> I'll add this: D-Bus is not a suitable transport for transfer of large
> blocks of data. It's not optimised for that. Please consider using a
> separate data channel, just like FTP.
>
> PS: I plan implementing that very framework for KIO RealSoonNow(TM).

That would be cool.

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