<div dir="ltr">Hi Vineet,<div><br></div><div>Let's tackle things one by one, before having a look into SSL itself and these other branches you created, please finish the refactoring. The agreed deadline is by the end of this month.<br><br></div><div>The CR that you sent breaks down several big files in smaller pieces and removes a lot of code, which looks super promising, but there are some issues that need to be polished. The main one is the coupling between Device and every type of Link, that needs some re-thinking. Other issues, though, are pretty simple and straight forward, so why don't you start by having a look at these?<br><br></div><div>Now, in reply to your email:<br></div><div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 8, 2015 at 9:04 AM, vineet garg <span dir="ltr"><<a href="mailto:grgvineet@gmail.com" target="_blank">grgvineet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><div dir="ltr"><div>"Pairing" should be property of 
device.<br></div></div></div></div></blockquote><div><br></div><div>That was the original idea, that's why all the Link types shared the same public and private keys originally. If we move the key to the Link as you did, this is no longer possible, because every Link will need to go through it's own pairing to get its key with a Device.<br></div><div><br>Note that we want to have more than one Link per Device, to be able 
to transition from one to another, so the approach of adding the "type" 
of link and having a single Link per Device doesn't work. Not only that, it's 
pretty bad that we need to change the Device class for every Link we add
 (that's huge coupling!). And also, how did you expect that type
 to be specified from the other side without adding a dropdown or 
"settings" menu before pairing, to chose the type? This approach has many issues so my impression is that you didn't think a lot about it before implementing it. Or maybe it's that you didn't know enough how we want KDE Connect to work, if that is the case, please ask here for any doubt you have and somebody will be able to help you!<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><div dir="ltr"><div>I have some 
ideas(to send some keys in packages that will not be sent by an device 
with old version of KDE Connect, so it will confirm that the device has a
 new version also device with old version of will not read those and it 
won't effect their working )<br></div></div></div></div></blockquote><div><br></div><div>We don't need to distinguish if a Device has an old version or a new version: since we will have both LinkProviders trying to find other devices at the same time, and they will use different ports, the old LanLinkProvider will find Devices that use LanLink and the new SslLinkProvider will find devices that use SslLink, in parallel. If a Device is found with both providers, we will create two links to the same Device, which is not an issue because the SslLink will have a higher "priority" than the LanLink, so the SslLink will be used.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><div dir="ltr"><div>Also
 added SslFIlter to socket connectors and acceptors in SslLinkProvider.<br></div></div></div></div></blockquote><div><br></div><div>As I said before, let's tackle the needed refactoring first. We need to iterate over that CM that you already sent, because it brings a lot of nice changes but it also needs some improvements to be perfect :)<br><br></div><div>Good luck with your exams!<br></div><div><br></div><div>Albert<br></div></div></div></div>