<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 7, 2015 at 2:58 PM, Albert Vaca <span dir="ltr"><<a href="mailto:albertvaka@gmail.com" target="_blank">albertvaka@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On Sat, Mar 7, 2015 at 1:06 AM, vineet garg <<a href="mailto:grgvineet@gmail.com" target="_blank">grgvineet@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
</span><span>> I have a couple of suggestions on it.<br>
> First of all I would like to know how packages are distributed in kubuntu,<br>
> may be we could add a "check for update" button in kubuntu version of<br>
> application.<br>
<br>
</span>No, we don't want to sneak around the distribution's packages manager.<br>
I'm actually a bit concerned about you suggesting this, first of all<br>
because we should care about every distribution, not only Kubuntu, and<br>
second because you say that you don't know how packages are<br>
distributed. What distro are you using that package distribution is a<br>
new thing for you?<br></blockquote><div><br></div><div>I use Kubuntu and use Muon package manager and discover or apt-get to install new packages, but I don't know how do we publish packages there.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><br>
><br>
> Or we could provide a link to old version of android application which does<br>
> not support ssl on application page of playstore.<br>
<br>
</span>This is not user-friendly nor easy to maintain.<br>
<span><br>
><br>
> Or the best one is to include "isSSLSupported" in identity package and have<br>
> a separate backend implementation for ssl and normal version, this would be<br>
> little difficult because simple socket can't connect to ssl server sockets<br>
> due to difference in protocols they follow, but it is achievable(May be we<br>
> need a SSLLanLink, SSLanLinkProvider and split Device into two, i.e normal<br>
> Device and SSLDevice).<br>
><br>
<br>
</span>This is in my opinion the way to go and I don't think it is that<br>
difficult. We should be able to have at the same time our current<br>
LanLinkProvider and a new SSLLinkProvider (maybe using a different<br>
port, so they don't clash). The Device should be completely unaware of<br>
the kind of Link that has underneath (that's the entire purpose of<br>
abstracting the links), so in no way we should need an SSLDevice.</blockquote><div><br></div><div>The part I wrote about Device is because current Device class handles public key, but we need to handle certificates in SSL, so we need to change  that, we also need to change pairing callbacks to store certificate instead of public keys. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div><br>
> I will further dig into it.<br>
><br>
> Vineet Garg<br>
><br>
<br>
</div></div><span><font color="#888888">Albert<br></font></span></blockquote><div><br></div><div>Still, I get your point and will sort out this problem and I will include it in my GSOC proposal.</div><div><br></div><div>Vineet Garg </div></div><br></div></div>