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.
Friday, February 20, 2009
Subscribe to:
Post Comments (Atom)
Posts
7 comments:
And Coherence is likely going to be the method of implementation right? Having one process deal with all UPnP communication makes sense to me.
If using Coherence is feasible is all to be seen.
Basically, we'd like to obtain two things:
- a general, easy to extend framework for supporting all UPnP-based profiles;
- a set of profiles already implemented with said framework, ready to use.
The framework should make implementing new profiles very easy: a way to do that would be offering the Jolie data manipulation syntax for manipulating the XML messages.
what i still didnt get.. lets say i want to have a simple shared scratchpad with jolie, nothing complicated. is there java needed on one of the machines? i wouldnt like the java dependency, but of course its perfectly valid if you use and like java.
thanks! mario
@Mario: yes, Java is a runtime dependency as long as you want to use Jolie (Jolie is an interpreter made in Java). Why would having Java be so much of a problem?
well not so much, its just personal preference :). you know you dont like to install huge deps only for one thing. i dont use other java apps. as i said for other people its probably no issue.
Well don't take too long deciding what framework to use lol, Amarok is already planning to use Coherence for GSoC partly because it was thought thats what Solid et. all would use.
You might want to talk to [ade], since he will start working to see how Coherence and KDE will fit.
At FOSDEM we had a very productive talk with people from Coherence and it looks like it is definitely compatible with the ideas I recently sent on the KDE hardware development list.
Of course, having two implementations is always ok for things like integration testing, squashing bugs, and so on :-)
Post a Comment