Solid, UPnP and Jolie
Lately there's been a lot of interest about UPnP and its application in KDE.
These days I'm speaking a lot about these things with Kévin "ervin" Ottens w.r.t. the Solid project. Even at Akademy 2008, Kévin suggested to me that it would be nice to have a UPnP protocol implementation in Jolie. There's been some discussion since there, but we just couldn't afford to implement it because of lack of resources (people/time). GSOC is approaching and this item is among the ideas for KDE, so some explanation is probably a good thing to offer. The aim of this post is to offer such an explanation, but given that I'm so familiar with Jolie I could miss some points of interest... so please *ask* if *you*'ve got doubts about this (like "I didn't understand why that point would be better than doing this other thing...", or "Did you think about using this and/or this?..").
Jolie is currently being integrated in KDE and will become a runtime dependency for activating Plasma on the network (making plasmoids in different machines communicating with each other, or with external services, etc.). Enabling Jolie to use UPnP would mean to re-use this dependency and all the technology developed until now (QtSodep, service composition, easy data manipulation etc.) for giving Solid (capital S) a solid backend (lower-case s ... yes, it's a pun! ha ha... *cough cough*) to exploit all the UPnP devices out there. Add to this the service-oriented programming capabilities of Jolie and you obtain a complete framework for making powerful orchestrators out of your UPnP network and even making Solid itself a UPnP service provider.
A note about the implementation: nowadays Jolie offers two ways for implementing a new protocol: you can write it in Java or write it in Jolie itself. We offer these two possibilities because it's useful to distinguish between low-level and high-level protocols, and to use the right tool for the right job.
The first kind deals with low-level byte streams manipulations, e.g. binary protocols, and Jolie is not suited to do that; good examples are any binary protocol, or even HTTP.
The second kind is more about manipulating data structures in an abstract manner; for example, suppose that you need to implement a new protocol on top of XML: being able to exploit Jolie's syntax for XML manipulation is usually a winner.
These days I'm speaking a lot about these things with Kévin "ervin" Ottens w.r.t. the Solid project. Even at Akademy 2008, Kévin suggested to me that it would be nice to have a UPnP protocol implementation in Jolie. There's been some discussion since there, but we just couldn't afford to implement it because of lack of resources (people/time). GSOC is approaching and this item is among the ideas for KDE, so some explanation is probably a good thing to offer. The aim of this post is to offer such an explanation, but given that I'm so familiar with Jolie I could miss some points of interest... so please *ask* if *you*'ve got doubts about this (like "I didn't understand why that point would be better than doing this other thing...", or "Did you think about using this and/or this?..").
Jolie is currently being integrated in KDE and will become a runtime dependency for activating Plasma on the network (making plasmoids in different machines communicating with each other, or with external services, etc.). Enabling Jolie to use UPnP would mean to re-use this dependency and all the technology developed until now (QtSodep, service composition, easy data manipulation etc.) for giving Solid (capital S) a solid backend (lower-case s ... yes, it's a pun! ha ha... *cough cough*) to exploit all the UPnP devices out there. Add to this the service-oriented programming capabilities of Jolie and you obtain a complete framework for making powerful orchestrators out of your UPnP network and even making Solid itself a UPnP service provider.
A note about the implementation: nowadays Jolie offers two ways for implementing a new protocol: you can write it in Java or write it in Jolie itself. We offer these two possibilities because it's useful to distinguish between low-level and high-level protocols, and to use the right tool for the right job.
The first kind deals with low-level byte streams manipulations, e.g. binary protocols, and Jolie is not suited to do that; good examples are any binary protocol, or even HTTP.
The second kind is more about manipulating data structures in an abstract manner; for example, suppose that you need to implement a new protocol on top of XML: being able to exploit Jolie's syntax for XML manipulation is usually a winner.