<div class="gmail_quote">On Wed, Mar 25, 2009 at 9:24 AM, Kevin Ottens <span dir="ltr"><<a href="mailto:ervin@kde.org">ervin@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Monday 23 March 2009 18:15:36 Rob Scheepmaker wrote:<br>
> I've mentioned my interest in this GSoC project before. Now I've made a<br>
> first draft of a proposal for GSoC.<br>
<br>
</div>Excellent!</blockquote><div>Indeed :-) <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
> A way to synchronize changes between multiple shared applets. It should<br>
> require only very little effort for applets to publish changes to all<br>
> shared applets, or receive changes from other shared applets. Again, I will<br>
> use Kevin Otten's library to make this easy.<br>
<br>
</div>Keep in mind that right now I'm concentrating on the "using services" part of<br>
the library. I'm somehow "forced" to put the "exposing services" part on hold<br>
because I'm waiting on some changes on Jolie's Metaservice side. AFAIK<br>
Fabrizio is working on that, but I don't really know when that'll deliver.</blockquote><div><br>At italianaSoftware we just finished the design of a feature I was waiting for which should solve all our problems w.r.t. security and service exposure.<br>
So the ETA is "not too far away". ;)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> The security implications will need to be thought trough. We will need some<br>
> some way of authenticating systems that are allowed access to published<br>
> applets or activities.<br>
<br>
</div>Oh, and once the library is ready to expose services, it's likely that for the<br>
first iteration it'll be a huge security hole. Jolie won't yet provide the<br>
security model, which means you'll be left on your own to authenticate<br>
clients. OTOH once Jolie provides a security model it won't be necessary for<br>
you to deal with that anymore (or at least it'll be much less complicated).<br></blockquote><div><br>The new feature I'm gonna put in Jolie should make it easy to "inject" security into unsecure services. We would still need to think the security model we want in our particular case (Plasma+Jolie). There are various possibilities, and the user should be prompted by Plasma when necessary. The sooner we start thinking about this, the better.<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
> Timeline<br>
> April 20 – May 22: Community bonding period, experiment with Kevin's<br>
> library, draft and discuss the required api. Draft and discuss the<br>
> interfaces for the required services.<br>
<br>
</div>Hmmm, April 20, I'll seriously have to move faster, and kick Fabrizio harder.<br>
;-)</blockquote><div>My god, we will have to write some documentation! ;-)<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
I'm seriously looking forward to your work. Obviously when the time comes I'm<br>
willing to mentor or co-mentor you. So far it's been always a pleasure to work<br>
with you, I'd be a fool not to participate in your mentoring. :-)</blockquote><div>I'm interesting in helping co-mentoring this, too. This will really put the qt/jolie integration to work.<br><br>Bye,<br>Fabrizio.<br>
</div></div>