Cloudeebus
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Subtitle |
| |
Alternative Title |
| |
Title of Series | ||
Number of Parts | 90 | |
Author | ||
License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
Identifiers | 10.5446/40273 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
FOSDEM 201367 / 90
2
5
8
10
12
13
14
15
17
19
21
24
25
28
29
31
32
34
36
39
40
43
44
46
50
51
52
54
55
57
58
62
65
66
67
78
79
87
88
00:00
Open sourceUniverse (mathematics)Point cloudDataflowBoss CorporationLecture/Conference
00:15
Proxy serverServer (computing)Tangible user interfaceMobile appPhysical systemStandard deviationInformation securityWeb serviceCommunications protocolWorld Wide Web ConsortiumComputer networkImplementationInformation securityServer (computing)Proxy serverInterface (computing)Web serviceMiniDiscCoefficient of determinationException handlingWeb 2.0AreaScripting languageComputing platformRow (database)Internet forumType theory
01:33
Interface (computing)Plug-in (computing)Scripting languageCodeServer (computing)Lecture/Conference
01:53
CodeBus (computing)Server (computing)Interface (computing)Lecture/Conference
02:09
Physical systemStandard deviationWeb serviceInformation securityWorld Wide Web ConsortiumComputer networkData managementServer (computing)HypermediaContent (media)Message passingModul <Datentyp>Mobile WebSoftware frameworkInformationClient (computing)Proxy serverInterface (computing)ImplementationArray data structurePell's equationData typeHypermediaCartesian coordinate systemObject (grammar)SoftwareServer (computing)Web applicationWeb serviceProxy serverCASE <Informatik>Instance (computer science)Library (computing)Message passingSoftware frameworkMereologyMobile WebComputing platformSocket-SchnittstelleWeb 2.0Solid geometryArithmetic progressionAreaBoss CorporationInternetworkingVotingDistanceSoftware testingLevel (video gaming)Group actionSystem of linear equationsXML
05:52
Pell's equationType theoryInterface (computing)ImplementationScreensaverError messageObject (grammar)2 (number)Exception handlingComputer programmingText editorWide area networkInterface (computing)State of matterFlow separationElectronic visual displaySoftwareScreensaverCuboidServer (computing)Proxy serverSound effectTouchscreenResultantSingle-precision floating-point formatComplex (psychology)Error messageMultiplication signForcing (mathematics)Game theoryScripting languageSystem callValue-added networkMessage passingMathematicsINTEGRALParameter (computer programming)Different (Kate Ryan album)FreewareCryptographyCodeBoolean algebraBus (computing)CASE <Informatik>RootFunctional (mathematics)Category of beingType theoryJSONXML
10:05
Server (computing)Client (computing)Client (computing)Graphical user interfaceServer (computing)Electronic mailing listScreensaverInformation securitySoftwareParameter (computer programming)Message passingCartesian coordinate systemState of matterLevel (video gaming)PasswordProxy serverPoint cloudResultantAsynchronous Transfer ModeObject (grammar)Open setWritingAuthorizationLine (geometry)BlogSystem callGroup actionOnline helpScaling (geometry)Single-precision floating-point formatCASE <Informatik>Demo (music)Revision controlConnected spaceHydraulic jumpComputer animationSource code
13:26
SoftwareLecture/Conference
13:39
Proxy serverXMLUML
13:58
Lecture/Conference
14:11
User interfaceVotingTelecommunicationLecture/Conference
14:29
Flow separationWeb serviceBoss CorporationFood energySingle sign-onPlug-in (computing)Connectivity (graph theory)Lecture/Conference
14:48
TowerCuboidLecture/Conference
15:06
State observerScripting languageServer (computing)Lecture/Conference
15:25
Lecture/Conference
Transcript: English(auto-generated)
00:00
Okay, so you never heard me play, so that's why you applause. Nice. So, I'm Lucuriat from Vintel Open Source Technology Center, and this talk is about Cloud E-Bus, like a d-bus for the cloud, which is a d-bus of proxies for our JavaScript.
00:30
Okay, so first I'm going to discuss why do we want at all to do d-bus proxies for our JavaScript and how we do it.
00:41
Then I go through the JavaScript API on how you can use d-bus proxy directly in JavaScript in a simple example. And then I show the server side of the stuff, so how you run the Python server, security and this kind of thing.
01:06
So, why? So, there are several reasons. The main is to implement HTML5 APIs on a different platform, so I go through it.
01:22
So, there are pros and cons on this thing. The nice thing is that almost every server, every low-level services in Linux has a d-bus interface. If you want to expose these interfaces to a JavaScript,
01:47
you'd have to write a native plugin or to write a CVS script, so that would be one piece of server code per d-bus interface. While here, you only do it once.
02:05
The cons is that while it only works on Linux, on the server side, and you obviously need to be able to restrict the d-bus access because you don't want to give your giving access to the Internet, for instance.
02:25
So then, where can you use this kind of thing? So, if you want to develop a network device, that exports part of its services on the network.
02:41
Or if you want to implement an HTML5 API on a given platform. So, let's go through some existing d-bus services that are pretty useful
03:01
and that you might want to use in a web app. So, we have Bluezine, which is Bluetooth, so it does object exchanges on networking. Tracker, so if you like SparkQL and you want to do web indexing,
03:23
that's the thing to do. Riggle for media services or Phono for telephony. Also, Nerd, so if you want to do NFC server. And then, on the HTML5 side, there are several APIs
03:42
that are more or less connected to this thing, like W3C, the device application group, they are starting to specify messaging, telephony, media capture,
04:07
but it's not frozen yet. You have Cordova, like PhoneGap, which does the same kind of thing for mobile. And Tazen, which is Linux OS with HTML5 API,
04:27
so right now it's all moving, it's not frozen yet, so you don't really want to work with an API if you have to handle it later. Hence, do it all on D-Bus and JavaScript.
04:46
So how do we do it? So that's a global picture. We have a Python server that acts as a middleman between the D-Bus services and the web app.
05:02
So it uses Autoban, which is a Python framework that does RPC, and also signal handling, which is built on Python 3.0 itself. And we use Python D-Bus library on the D-Bus end,
05:24
and the Python JSON library to exchange the JSON messages through web sockets. OK, so now we'll go through the D-Bus proxy API.
05:43
So what's a D-Bus proxy? So in case you haven't used D-Bus at all. So a proxy is a reference to an object on the server. It has a property that can be of simple type or complex, like a dictionary, an array, and so on.
06:02
It implements interface with a method, and you can register a callback on a proxy to respond on a D-Bus signal. An example.
06:21
So the screen-saver GNOME interface. So here there are three methods and one signal. So the getactive method returns a boolean that says if the screen is locked or not.
06:41
The setactive method locks the screen, or unlocks it. And the showMessage method displays a message on the screen while the screen is locked. And then there's an active change signal that is triggered every time the screen is locked or unlocked.
07:04
And it sends a boolean that says if the screen is locked or unlocked. So it's all straightforward. How would you program this in Python with a Python proxy? So here it's really straightforward.
07:22
You get a handle on the session bus. You get the screen-saver root object and the screen-saver interface on this object. And then you just call the method. So here this code would lock the screen, display a message that says hello, Python D-Bus is called,
07:45
sleep for three seconds, and unlock the screen. So now if you would like to do the same thing in JavaScript, first the big difference would be that JavaScript is asynchronous here.
08:03
So instead of calling method foo with parameters x, y, and getting a result, you'd call method foo, pass a couple of handler functions who want to get a result in case of error.
08:24
And in the reply handler, you get the result. So here, instead of of.foo x, y, you do of.foo x, y, reply and error. So it's the same thing.
08:42
That is synchronous. So now if I want to do the same thing in Python that locks the screen, displays a message, and unlocks it, after D-Bus, so first I would connect to the server.
09:00
So here it's on the local host. I have this callback when I'm connected, or I do pretty much the same thing as in Python, so I get the session bus, I get a proxy on the screen's server object, and here I pass a callback
09:22
that's called when the proxy is introspected. So the introspect function reads the XML data and adds the method to the object. So here I can lock the screen, just like in Python,
09:44
for a message. Instead of sleeping, so in a JavaScript, I set a timer for three seconds, and after three seconds, I display the lock state
10:01
and unlock it. And I'm courageous, I can try it. So one, two, three, it's unlocked. And the lock message is here. So you see in this case, I use the object,
10:21
I have introspected the object in a synchronous callback. I can also use it directly in a lower level API. So here, same thing, I get the proxy,
10:41
but I don't pass a callback for introspection. And instead of locking it by doing proxy.setactive, I have a more cumbersome method.
11:01
I call the method, giving the interface, the method name, and the argument. And of course, I can add a callback after that if I want a result. I also connect through the lock signal. And so when I get those signals,
11:21
so I log the state change, I disconnect, and I unlock it. So here it's barely gonna blink, not even, okay? So it says, okay, it's changed. I know it's unlocked. So that's this log here, and this log.
11:46
11, all right. Okay, so just a quick glance on the server side. So Cloud E-Bus on the server side is a Python server.
12:05
You can run it without a security enable in open door mode. So here, everybody can access to E-Bus, which is good for demo,
12:21
but you don't really want to do this in real life. Or you can add credentials and a wait list. So I'll add an example here. So on the server side, I put a wait list.
12:42
I say the client can only access, so here are Nautilus and our screen saver. The only user I know are Cloud E-Bus, user one, user two, so it's user and password. And on the client side,
13:02
the application has a manifest pretty much like a Chrome manifest with user, version, password, and permissions that it wants to access. So the handshake is handled by Autobahn,
13:25
which encrypts the password through the networks so they don't go unencrypted. And that's about it. So next, I have to export services,
13:42
import it on Node.js. That's done already. And I'll do a bunch of stuff. I take patches, so if you want to participate, you're welcome. Thanks.
14:09
Why do I choose D-Bus and not something like 0C-ICE? ICE is something with a lot of success in the communication world.
14:23
Well, actually, I had to vote web interface for several D-Bus services, so NFC, telephony, DLN, and stuff.
14:41
And at the end of the day, instead of writing one in PPI plug-in per component, I thought it was much more easier to just take the whole D-Bus thing and pull it to JavaScript.
15:02
So I didn't have the use for the server, so I just did it
15:21
because the server I wanted to expose to JavaScript was already using D-Bus. Thank you.