GSOC update

vineet garg grgvineet at gmail.com
Tue Jun 9 15:38:22 UTC 2015


On Tue, Jun 9, 2015 at 12:38 PM, Albert Vaca <albertvaka at gmail.com> wrote:

> Hi Vineet,
>
> First of all, please push soon the refactor you made as part of your first
> milestone. I think I gave you a "Ship it" already. According to the
> schedule, it should have been merged before May 30th, and I can see it's
> not done yet.
>
>
That change is not pushed because I considered new approach to be much
better and didn't wanted not so much good approach in master branch. I am
maintaining a branch named gsoc locally and also on github. So if needed
that commit can be easily pushed onto master.


> The next step according to the roadmap is: "15 June -> SslLink link
> implemented on Android, code-reviewed and merged." How are we tracking on
> that goal? It's okay to me if you decide to work on the tests first, but
> please make sure that you don't take longer than initially planned for both
> things. I already commented on the code review you sent with the
> tests. It's very nice to finally have a testing framework in place for KDE
> Connect in Android :D
>
> About the SSL link, I saw the changes in your Github repo. I would like to
> know what are the reasons for re-using the LanLink instead of creating a
> new type of Link. Is it better this way? Why?
>

Firstly due to too much simplicity in mina to use ssl, writing a new
SslLink will cause a huge amount of code duplication. Secondly I don't
think creating two links for a device where only one will be used most of
the time is a good choice. It will just cause a lot of overhead on device.
Even in Qt, no need to for a separate SslLink, we can just use QSslSocket
instead which will work as normal QTcpSocket until, startServerEncryption
or startClientEncryption is called. These changes will not make any code
duplication, unnecessary extra link, will be fully compatible with older
devices.


>
> Finally, about testing with two phones, it is definitely going to be
> better than using two emulators, but actually the emulator should work as
> well. I have two phones, so I should be able to test your changes, but I
> haven't had time to do it yet and you shouldn't rely on me having free time
> to test it. Keep me posted on when you think you will be able to go back to
> working on this (either getting a second phone or making the emulator work).
>

Android emulator can't work in bridged mode, a lot of port forwarding is
needed that creates a huge problem. Have to wait for new device until
coming Monday till than I will be writing some more tests for link provider
and link.

I will get my new device, so I guess the 15 deadline is little screwed now,
but currently writing tests now to not waste any time. By the time the
deadline for tests is over, we will have both, working application and
tests.

Vineet

>
> Happy hacking!
>
> Albert
>
> On Fri, Jun 5, 2015 at 4:41 AM, vineet garg <grgvineet at gmail.com> wrote:
>
>> Hi,
>> I have been working with ssl with mina for past few days. While testing I
>> realized that there are some compatibility issues with mina that it is not
>> working in emulator properly. The same code when tested with openssl cli is
>> working on physical device but not working in emulator correctly.
>>
>> Due to simplicity of mina to handle ssl via filter, I was able to add ssl
>> filter in session within LanLink, both device if supports ssl, ssl will be
>> started. If even one device is old, the ssl won't be started and normal
>> link proceeds. Have a look of the code, available at "
>> https://github.com/grgvineet/kdeconnect-android/tree/sslinlanlink", also
>> test it whether it works on two physical device if possible.
>> Currently device trust all certificates in all connections. Method to
>> check for remote device with its certificate is added but not tested yet
>> and not in use currently.
>>
>> Since I have only single device, I am not able to test it properly.
>> Planning to buy new phone, but that is only available Thursday in flash
>> sale at Amazon. So I have to wait for a week plus the time it will take to
>> reach home.
>>
>> I am thinking to preempt this for some time and get my hands dirty on
>> Android testing framework. What do you suggest ?
>>
>> Vineet
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150609/c6dba1e5/attachment.html>


More information about the KDEConnect mailing list