Remote dataengines working.

My SoC project is now at the point where not only remote Plasma::Services are working, but remote dataengines too. Which means I’m now actually running a nowplaying applet in my virtual machine which shows what I play using Amarok on my other machine. This applet can also be used to control that remote amarok, just like it would when run locally. And all this didn’t require any change to the nowplaying applet or dataengine, only an entry in the nowplaying applet’s configuration instructing it where the nowplaying dataengine should point to. Pretty neat right? Here a screenshot, because people like pictures:

Remote dataengine in action.

Next step is supporting blue tooth like passkey pairing: when an untrusted machine connects, both sides can input a password, and if both passwords match, access is granted. Stay tuned!

Advertisements

11 Responses to “Remote dataengines working.”

  1. Chris Says:

    Congrats πŸ™‚

    But can we get that not only with passwords but also with stuff like ssh keys so I don’t have to remember / enter some passwords all the time but it “just works” for trusted machines?

    IMHO much more comfortable and secure enough for random dudes home usage.

  2. rscheepmaker Says:

    @Chris: of course there’s the possibility of just importing keys of trusted machines… it should be possible to build a computer into the wall that still serves dataengines and services. Not only that, even when using password pairing, you’ll only have to do it a single time: after that we have and can trust the connecting machines public key, so if you want you can allow that machine access to all you plasma services (probably by checking a checkbox in the password dialog: ‘always allow this user’).

  3. Elias P. Says:

    This is IMHO one of the greatest Plasma innovations during the last 2 years.
    I’m really eager to try this out – will this work using KDE 4.3 or will it require 4.4?

    Regards, Elias P.

  4. rscheepmaker Says:

    @Elias: it will be 4.4. 4.3 is almost released, and has been in feature freeze for a while already. Plus there’s still enough work to do to make this a smooth experience: the mentioned passkey pairing, the ability to also fetch the plasmoids package from the remote machine, zeroconf support, GUI bits for publishing and accessing services. So you’ll still have to be patient for a little while.

  5. notoveryet Says:

    I can’t wait to try it out…

  6. k3ks Says:

    I really want to try this πŸ™‚
    Is there code I can try? I guess it lacks an config gui atm, so is there also description how to configure that?

  7. rscheepmaker Says:

    @k3ks: Currently I’m still working in a local git branch. Besides, setting it up to work is currently a bit of a pain cause of the lack of GUI. For example, for having the nowplaying dataengine published, I’ve hacked a call to dataEngine::publish into the nowplaying applet, since there’s not yet a config option for that. Also you’ll need my forked plasmoidviewer which implements AuthorizationInterface, and for easy testing that class also considers any public key it receives as trusted which is inherently very unsafe, but makes testing easier.
    I’ll probably push this branch somewhere on svn once those very rough bits are ironed out.

  8. A B Says:

    This is great.

    Can you give us a hint of the underlying mechanism of this network transparency thing and how it works under the hood?

    Also can you give us some ideas how can we exploit this feature .. do you have more examples of how in the future can we use these network transparent plasmoids?
    Or will we need KDE Brainstorm?

    Regards,

  9. rscheepmaker Says:

    @A B:
    Under the hood is uses JOLIE (http://jolie-lang.org) through QtJolie. It sends jolie messages to the requested service (where a published dataengine itself is also an Plasma::Service implementation). Every message get’s digitally signed so that the caller can be identified, and tested against a set of rules to see if the operation is allowed. A plasma shell can implement an interface to handle requests that don’t already match any rule so they can interactively ask the user whether or not it is allowed. Plasma::Service uses KConfigGroups in combination with KConfigXt to specify which operations are allowed and which parameters are needed. These parameters get put into the JOLIE message, send to the remote machine which sends the result back after authentication.
    This is short and very global but hopefully it will give you an idea. Some larger explanation including header files showing the current API can be found on the plasma-devel mailing list. I’ll probably blog about the inner workings within a couple of weaks, but it’s already quite a complex beast.
    For more ideas on what to do with it, you can look at:
    https://pindablog.wordpress.com/2009/04/21/gsoc-2009-network-transparency-in-plasma/
    There are many many more ideas already though. But feel free to post some suggestions in KDE brainstorm, there are quite some possibilities for this technology.

  10. Lukas Says:

    Man, Its just awesome πŸ˜€

    Does this means, that I would be able to put multimedia-center-PC under my tv, and use my laptop or even smartphone as remote control? Just as simple as weather plasmoid? πŸ˜‰

  11. rscheepmaker Says:

    @Lukas: exactly… and that’s just one of the many possibilities. πŸ™‚

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: