Re: io-slave design-problem

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: io-slave design-problem
by michael on Thursday 12/Apr/2007, @02:27

The main problem is that it gets a lot more difficult to implement at a deeper layer. Even now ioslaves have some complex issues to solve.

One of them is that most interresting ioslaves may require user interaction.
lets say "less http://kdenews.org" actually works but the given URL requires authentication. "less" obviously can't handle that, so what will?

What about progress bars? Even small files may take a long time to access. And in many cases "download, work locally, upload" is the only reasonable approach to work with a file.

Related Links

·   Articles on KDE Public Relations and Marketing
·   Also by michael
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: io-slave design-problem
by Philipp on Thursday 12/Apr/2007, @04:07

I'm pretty much sure all of the issues can be solved.

It would just need a deeper interaction between a generic library and the above DE / applications. Even the mentioned interactions can be done.

For sure it is a huge task getting it done in a way every DE / app is accepting it and the flexibility in adding new / adjusting current IO-slaves from one to another KDE version is gone. I.e. it needs to be at least pure LGPL so it cannot be done with Qt.

But I don't see a fundamental reason why it shouldn't be possible.

[ Reply To This | View ]

Re: io-slave design-problem
by Kevin Krammer on Thursday 12/Apr/2007, @05:30

> I'm pretty much sure all of the issues can be solved.

There has been at least one attempt for a unified VFS implementation (look for D-VFS in the archives of the xdg mailinglist on freedesktop.org).

However, main author/developer got lots of negative feedback from people not associated with any desktop project and gave up.

> it needs to be at least pure LGPL so it cannot be done with Qt

That's not an issue. Any such system would be out of process, i.e. a single daemon or multiple daemons (one for each connection like KIO slaves, or one for each protocol or one for each host, etc).

Since communication would happen through a specified protocol (also the way KIO slaves work), the licence of each side of the communication does not influence the licencing options of the other.

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"Ok, maybe my approach is over-engineered." -- Simon Hausmann
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.