GSoC proposal draft: network transparency.

[Kevin Ottens]

On Monday 23 March 2009 18:15:36 Rob Scheepmaker wrote:
> I've mentioned my interest in this GSoC project before. Now I've made a
> first draft of a proposal for GSoC.

Excellent!

I think the use cases and personae is very good, I'll just add some more 
information (for you, not necessary to be in the GSoc proposal) on the parts 
about the Qt/Jolie integration.

> Requirements
> This section contains an overview of the components that are needed.
> Network transparent Plasma::DataEngine and Plasma::Service. I will use
> Kevin Otten's services framework to make this work easier. This library is
> currently still a work in progress, but it's nearing completion and will
> most likely be completed once GSoC starts.

I hope it'll be completed before GSoC starts, but keep in mind that I made no 
promise so far. ;-)

It's lagging behind because my fridays were full of other stuff (in particular 
for the uni), but starting with this friday it should be slightly better.

> The API of this library will be
> very much like Qdbus, only network transparent.

Yes, that's exactly what I have in mind. I was pondering between something job 
based or something looking like QtDBus. But from the different uses of the 
library and the service orientation it seems adequate to make it similar to 
the QtDBus API.

> A way to synchronize changes between multiple shared applets. It should
> require only very little effort for applets to publish changes to all
> shared applets, or receive changes from other shared applets. Again, I will
> use Kevin Otten's library to make this easy.

Keep in mind that right now I'm concentrating on the "using services" part of 
the library. I'm somehow "forced" to put the "exposing services" part on hold 
because I'm waiting on some changes on Jolie's Metaservice side. AFAIK 
Fabrizio is working on that, but I don't really know when that'll deliver.

> The security implications will need to be thought trough. We will need some
> some way of authenticating systems that are allowed access to published
> applets or activities.

Oh, and once the library is ready to expose services, it's likely that for the 
first iteration it'll be a huge security hole. Jolie won't yet provide the 
security model, which means you'll be left on your own to authenticate 
clients. OTOH once Jolie provides a security model it won't be necessary for 
you to deal with that anymore (or at least it'll be much less complicated).

> Timeline
> April 20 – May 22: Community bonding period, experiment with Kevin's
> library, draft and discuss the required api. Draft and discuss the
> interfaces for the required services.

Hmmm, April 20, I'll seriously have to move faster, and kick Fabrizio harder. 
;-)

I'm seriously looking forward to your work. Obviously when the time comes I'm 
willing to mentor or co-mentor you. So far it's been always a pleasure to work 
with you, I'd be a fool not to participate in your mentoring. :-)

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090325/3150e1e7/attachment.sig