[GSOC] Progress

[Albert Vaca]

Hi Vineet,

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.

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?

Now, in reply to your email:

On Fri, May 8, 2015 at 9:04 AM, vineet garg <grgvineet at gmail.com> wrote:

> "Pairing" should be property of device.
>

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.

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!


> 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 )
>

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.


> Also added SslFIlter to socket connectors and acceptors in SslLinkProvider.
>

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 :)

Good luck with your exams!

Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150511/fbb18d91/attachment.html>