Thursday, July 24, 2008

Vision: a distributed presentation framework.

Vision is a proof of concept application (thanks aseigo for the initial suggestion), showing what can be easily obtained by using the service-oriented paradigm together with rich client applications.

What is Vision?
But, more importantly: what's a distributed presentation?

Imagine that you are showing a presentation, and that someone wants to see what you're presenting... in his computer! To do so, he should connect in some way to your presentation. Whenever you change page (or make another relevant action, like changing document), the client should be notified and synchronized automagically.
That is exactly what Vision does. It forms a network between the presenter and the clients, keeping the clients synchronized with the presentation.
A screencast is better than a thousand words: an example usage of vision with the previewer plasmoid and kpdf.

As you can see in the screencast, Vision already supports more than one viewer (there are shown kpdf and the previewer plasmoid, but we also already support okular).

Another nice feature of Vision is that it forms a P2P network. A client acts also as a presentation server. Say that A is watching B's presentation. Now another client (C) can connect to A. Whenever A receives an event from B, it will now also send it to C.
This can be exploited, for example, in order to perform bandwidth load balancing.

Note also that Vision makes use of SODEP, a binary protocol especially designed for service communications (it can, nevertheless, use all of the other JOLIE supported protocols, such as SOAP, HTTP, GWT-RPC...). Thus, the needed bandwidth is very small and the application can handle a lot of clients at the same time.


Exposing Vision to other platforms
A great feature of JOLIE is that it separates the logical interfaces of a service from their deployment. Suppose that we want to extend Vision to support Bluetooth clients. The ideal solution would be to expose the same interface that we expose on the network via sockets to bluetooth. Luckily, doing that in JOLIE is very easy:


service PresenterBluetoothService
{
Location: "btl2cap://localhost:3B9FA89520078C303355AAA694238F07;name=Vision;encrypt=false;authenticate=false"
Protocol: sodep { .charset = "ISO8859-1"; .keepAlive = 1 }
Ports: PresenterInputPort
}


What do these lines mean?
Well, they're telling JOLIE to expose the PresenterInputPort interface (which is the Vision presenter interface) on the pointed bluetooth Location using the SODEP protocol to encode and decode data. You can see the whole presenter service code in the JOLIE SVN repository (/trunk/playground/vision).

Guess what? It just works! (video) And what's better than a mobile phone to test it?

By the way:


just in case you want to see more service-oriented goodness in KDE. =)

8 comments:

mutlu said...

I am speechless. This is soooo cool!

Lukewarm Rosewater said...

Man, this is just fabulous! A fantastic idea, keep up the good work! This can really be a killer app.:)

Few questions that come to mind, to make it rock even harder: Are you planning, somewhere in the future, on adding a GUI? Since, as you say, it forms a P2P network, will it work over a NAT? Support local service discovery, or allow connecting in a non-tech-user-friendly way? (I'm thinking here about possible classroom / distance learning use, and maybe also as a partial replacement for all kinds of Remote Assistance apps. I guess it would really help adoption if configuration was as painless as possible.) Anyways, great job, thanks so much:)

Aaron J. Seigo said...

> on adding a GUI?

one word: Plasma =)

having a generic network layer for widgets was one of the original Plasma design goals.

up until fmontesi came along with JOLIE it was under the "research" column and was most likely something for KDE 4.4 or thereabouts, and would have been much simpler and less powerful than JOLIE is today.

i was so excited when he and his research partner agreed to join us at Tokamak in April.

the idea is to mate the two technologies (JOLIE and Plasma) together so that all Plasma apps benefit from it transparently (so, the workspace, krunner, amarok2, devices that ship with libplasma, etc)

the idea is thus:

a) we'll provide a service advertiser in plasma, perhaps merged with the device notifier UI

b) Plasma::Service becomes a transparent bridge to JOLIE, so DataEngines, widgets and apps write Plasma::Services and they work either locally or remotely automagically

c) Plasma will advertise and help enforce the security boundaries with JOLIE

d) Plasma widget packages (aka plasmoids) will be transportable along with JOLIE services

most or all of this will ship in 4.2.

as the default shell for the KDE4 workspace, the widget engine in Amarok2, the guts behind krunner and shipping on various devices in the future (not to mention available for both Mac OS and Windows), libplasma will help bring JOLIE to the average user and thus make it of greater interest to the average developer.

that's the idea anyways. =)

fmontesi said...

As for the other answers:

> Since, as you say, it forms a P2P network, will it work over a NAT?

We're currently refining the details of this, but you will probably just need to open one TCP port. It's easy to add UPnP support to JOLIE, if you want that. That single TCP port will be the access point for _all_ of the JOLIE<->Plasma services running in your computer.

> Support local service discovery, or allow connecting in a non-tech-user-friendly way?

Absolutely yes. =)
Also, services can be equipped with metadata (JOLIE does not put any limit to this), so it would be possible to put any necessary data to make even some AIs that go on the network looking for the services it wants. I expect people to come up with something like this once we've given them the power to concentrate just on the logic of their distributed applications and not on the implementation details (basically, this last sentence is what JOLIE does: leveraging the service programmer from the underlying details and code the workflow of its application).

This is just the tip of the iceberg, the possibilities are even much more than this.

Thomas said...

I would love to see a plugin for KPresenter (using the koffice docker plugin structure) so people can see the kpresenter slides on their mobiles :)

fmontesi said...

> I would love to see a plugin for KPresenter (using the koffice docker plugin structure) so people can see the kpresenter slides on their mobiles :)

That is certainly possible and it is an objective for Vision. The only thing that we need is to make a JOLIE service wrapper for KPresenter (which is not difficult at all). Then, we're all set for odp presentation goodnees. ;)

I'd prefer to make this directly for KOffice 2, instead of doing it now for the old KOffice and do it again for the new one. Looks like KOffice 2.0 is on its way to stabilization, so this could happen in the not-so-very-distant future.

André said...

This is just amazing. Extremely cool! Keep up this work!

Riothamus said...

This sounds like Microsoft's NetMeeting on steroids. My company uses NetMeeting a lot, and I was hoping for something that could match (or exceed that) as a built in app for KDE. Keep up the good work!