On Tuesday 05 March 2002 17:01, Holger Freyther wrote: > 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. Good thinking! I thought a .desktop file flag was needed anyway, so that we directly find from the trader which part could support streaming for the datatype we have, but your remark below proves this wrong: > 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? Yes, that sounds quite good. Although at the moment I don't know any part that supports progressive loading for only some of the types it shows, that flexibility will most probably be needed. Compared to the internal IO slave, I like the idea of the virtual methods because they're much more straightforward. Less "hidden magic" involved. Waldo: ok if I commit those virtual methods ? -- 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