<div dir="ltr">Yep, it must be a cool thing, but i don't think that it is a good idea.<div>1) All this p2p stuff has a listening port. (requires configuration, upnp and so on)</div><div>2) Some protocols requires pre-configuration. For ei dc++ requires hub and unique nickname.</div><div>3) In p2p world it's good to sid what u've downloaded. How that should be implemented with kio?</div><div>4) Several different protocols in one thing - re implementing mldonkey in kio - i don't think it'a good idea.<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 25, 2015 at 1:00 AM, Aleix Pol <span dir="ltr"><<a href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, May 16, 2015 at 1:31 PM, Vladimir Perepechin<br>
<<a href="mailto:vovochka13@gmail.com">vovochka13@gmail.com</a>> wrote:<br>
> Hi everyone :)<br>
><br>
> I was thinking about implementing my idea<br>
> <a href="https://forum.kde.org/viewtopic.php?f=83&t=126352" target="_blank">https://forum.kde.org/viewtopic.php?f=83&t=126352</a> .<br>
> While digging sources i've understand that my idea was incorrect, and there<br>
> is nothing to do with kio_magnet.<br>
><br>
> My second thought was to store any additional info in mimeinfo while<br>
> detecting it from url, but after more digging i came to mime subclasses.<br>
> In fact,  i understand that x-scheme-handler is very simple in the way how<br>
> it determines, but i've tried to add subclass for it ad it works like for<br>
> any other mime-types.<br>
><br>
> The only problem is: KRun dosn't looking into mime-database when working<br>
> with x-scheme-handlers. So i came here with  the following proposition.<br>
><br>
> Extend schemeHandler function of KRun.<br>
> 1) we are looking for all mime-types that statrs with x-scheme-handler and<br>
> has base handler in a parentMimeTypes.<br>
> 2)If we found such mime-type - check url against globPatterns of found<br>
> mime-type.<br>
><br>
> 3) So, if we found subclassed mime-type for our url - try to find preferred<br>
> service for it. if no preferred service was found - looking for preferred<br>
> service for our base mime-type (as it was done before)<br>
><br>
> So, it will be something like this: <a href="http://pastebin.com/Wgni5iBP" target="_blank">http://pastebin.com/Wgni5iBP</a><br>
> I'm not a c++ coder, so this isn't most optimized solution, but it shows the<br>
> idea.<br>
><br>
><br>
> Next step:<br>
> Just ship xml with magnet url subclass with ktorrent:<br>
> <a href="http://pastebin.com/4crCJRLZ" target="_blank">http://pastebin.com/4crCJRLZ</a><br>
><br>
> And add x-scheme-handler/x-magnet-btih to ktorrent.desktop MimeType list.<br>
><br>
> Doing similar with other magnet handlers (like dcpp) will allow us to<br>
> separate magnet handling by appropriate application.<br>
><br>
><br>
> So, what do u think? Is this idea wrong? Any other ideas?<br>
<br>
</div></div>Maybe you'd like to work on the kio-magnet? I think it could be a<br>
really cool thing to have.<br>
<span class="HOEnZb"><font color="#888888"><br>
Aleix<br>
</font></span></blockquote></div><br></div></div></div>