Application-Sharing – Übersicht und

Hochschule für Technik, Wirtschaft und Kultur Leipzig (FH)
Fachbereich Informatik, Mathematik, Naturwissenschaften
Mario Wenzel
10MIB2
Application-Sharing
Übersicht und Beispielanwendung
Juli 2011
Inhaltsverzeichnis
I. Einleitung..........................................................................................................................................2
II. Entferntes, kollaboratives Arbeiten mit Gobby/Infinote..................................................................3
III. Entferntes, kollaboratives Arbeiten mit Google Docs....................................................................5
IV. Kollaboratives und unabhängiges Arbeiten an einer Arbeitsstation mit MPX...............................7
V. Screen-Sharing per VNC..................................................................................................................8
VI. Möglichkeiten des Broadway-Interface in GTK+3.2...................................................................10
VII. Zusammenfassung und Beispielanwendung...............................................................................11
VIII. Abbildungsverzeichnis...............................................................................................................13
IV. Quellen..........................................................................................................................................13
I. Einleitung
Kollaboratives und entferntes Arbeiten sind unerlässlich in der modernen wissenschaftlichen Welt
und in modernen Wirtschaftsprozessen.
Von 1990 bis zum Jahr 2005 hat die Zahl der wissenschaftlichen Arbeiten mit über 50, 100, 200 und
500 beteiligten Autoren stetig zugenommen[drgs]. Diese Forscher kommen nicht selten aus
unterschiedlichen Instituten, Ländern oder Kontinenten. Die Kommunikation kann nicht
ausschließlich von Angesicht-zu-Angesicht erfolgen. Regelmäßige Treffen internationaler Gruppen
von Forschern, zum Beispiel zum Austausch von Ideen oder Ergebnissen, sprengen auf Dauer jedes
Forschungsbudget. Auch per Telefon lassen sich Forschungsergebnisse schlecht austauschen.
Digitale Kommunikationsmittel sind für die Planung und den Austausch von
Forschungsergebnissen unabdingbar. Daraus ergibt sich ein erhöhter Kommunikationsbedarf über
das Internet und ein Bedarf für neue Werkzeuge und Methoden zum kollaborativen Arbeiten.
Aber nicht nur das kollaborative Arbeiten hat an Wichtigkeit gewonnen, auch das entfernte
Arbeiten. War es bis Ende der 80er Jahre noch üblich, Berechnungen und Simulationen auf
Großrechnern ausführen zu lassen, ist ein großer Teil dieser Rechenleistung heute von DesktopSystem aufbringbar. Trotzdem sind Cloud Services (entfernt bereitgestellte Dienste) in den letzten
Jahren enorm gewachsen. Amazons EC2-Service [aws] generierte für das Unternehmen im Jahr
2010 über 500 Mio. USD Umsatz, im Jahr 2011 geht man von 750 Mio USD aus, 2014, wenn der
Trend sich fortsetzt, 2,5 Mrd. USD [crn1]. Amazons Kunden können über die EC2-Cloud-Plattform
die unterschiedlichsten Dienste anbieten. Hierbei ist es denkbar, dass auch Desktop-Applikationen
der verschiedensten Art für mobile Endgeräte (bzw. den mobilen Nutzer auf verschiedenen
Endgeräten) bereitgestellt werden, denen es selbst an Speicher und Rechenleistung, jedoch nicht an
Bandbreite mangelt.
Seite 2
Diese Arbeit beschäftigt sich mit den Möglichkeiten des entfernten, kollaborativen Editierens von
Textdateien mit der freien Software „Gobby“ (Kapitel II) und dem entfernten, kollaborativen
Bearbeiten von Dokumenten mit Google Docs (Kapitel III). Außerdem werden VNC (Kapitel IV)
und MPX (Kapitel V) auf deren Tauglichkeit zum kollaborativen Arbeiten geprüft, sowie das
Broadway-Interface für GTK+ vorgestellt (Kapitel VI).
II. Entferntes, kollaboratives Arbeiten mit Gobby/Infinote
Gobby [gby] ist eine OpenSource
Software um kollaborativ in Echtzeit
über eine LAN oder WAN-Verbindung
Textdateien zu bearbeiten. Das GobbyProjekt steht unter der GPL-Lizenz. Es
stehen Binärpakete für Windows und
Linux bereit, kann jedoch auf auf Mac
OS X und anderen Unix-Systemen
kompiliert und genutzt werden [gbydwn].
Abb. 1: Gobby unter Ubuntu/Gnome3 - Editieren einer
php-Datei mit entspr. Syntax-Highlighting
(Oktober 2008) das Protokoll „obby“ und seitdem die projekteigene Infinote-Bibliothek (libinfinity)
Gobby benutzte bis zur Version 0.4.90
[gby1].
Gobby arbeitet mit einem Client-Server-Modell, wobei kein dedizierter Server notwendig ist, da
jeder Client die Server-Funktionalitäten beinhaltet. Es ist jedoch auch möglich, einen dedizierten
Server1 zu nutzen.
Ein Nutzer eröffnet eine sog. Sitzung, die auch Passwort-geschützt sein kann. Andere Nutzer
können dieser Sitzung beitreten, in dem sie die IP-Adresse und Port des Serverdienstes in die
entsprechende Verbindungsmaske eingeben. Im LAN nutzt Gobby aber auch Zeroconfig (zum
Beispiel avahi [avahi]), um Sitzungen bekannt zu machen. Durch die Verwendung von Zeroconfig,
einer automatischen Konfigurationsmethode für Netzwerkdienste, kann ein Nutzer auch ohne die
Kenntnis der IP-Adresse des Servers einer Sitzung beitreten (im lokalen Netzwerk verfügbare
Sitzungen werden in einer separaten Liste angezeigt und können dort ausgewählt werden). Beim
Eintreten in eine Sitzung wählt der Eintretende seinen Nutzernamen und eine Farbe, in der seine
1 „Sobby“ für das obby-Protokoll und „infinoted“ für infinote
Seite 3
Änderungen in den Dokumenten der Sitzung dargestellt werden (Siehe Abb. 1, mitte) sollen. Diese
Farbe kann jedoch im Verlauf der Sitzung vom Nutzer selbst sowie dem Sitzungseröffner oder
berechtigten Nutzern geändert werden.
Die Änderungen, welche die Nutzer am Dokument durchführen, werden von allen anderen Nutzern
sofort gesehen. Die eingebrachten Änderungen werden hierbei zeichenweise übertragen. Die
Verzögerung, die die Nutzer hierbei erfahren, ist nur durch die entsprechenden Latenzzeiten zum
Server begrenzt (i.d.R. wenige 10 Millisekunden).
Nun können alle Teilnehmer der Sitzung Textdateien in die Sitzung hineinladen (entsprechendes
Syntax-Highlighting, also das kontextsensitive farbliche Auszeichnen von zum Beispiel
Programmcode kann clientseitig aktiviert werden). Die geladenen Dateien befinden sich nun als
temporäre Dateien auf dem Server. Alle Teilnehmer, auch der Sitzungseröffner und der Teilnehmer,
der die Datei zur Bearbeitung eingebracht hat, müssen die Sitzungsdateien wieder auf ihren lokalen
Computer abspeichern, um Änderungen über die Sitzung hinaus zu sichern.
Um die Kommunikation zwischen den Teilnehmern zu gewährleisten, bietet Gobby einen IRCartigen Chat (Siehe Abb. 1, unten). Der Chat ist jedoch nicht nach Dateien getrennt und so kann es
schon bei wenigen aktiven Nutzern (ab 5) für die einzelnen Teilnehmer schwierig werden, die
Übersicht zu behalten. Ebenso gibt es keine Möglichkeit zu sehen, an welcher Stelle (bzw. in
welcher Datei) die anderen Teilnehmer ihre Änderungen zu einem bestimmten Zeitpunkt
vornehmen. So ist es bereits bei kleineren Dateien (100 Zeilen) kompliziert, alle Änderungen der
anderen Teilnehmer zu verfolgen, wenn diese Änderungen an mehreren Stellen im Dokument
vornehmen.
Wenn die Dateien der Sitzung auf die Computer der Teilnehmer zurückgespeichert werden, gehen
alle Informationen darüber, welcher Teilnehmer welche Änderungen eingebracht hat, verloren.
Werden die Dateien dann in ein Versionsverwaltungssystem (Subversion, Git, Bazaar o.Ä.)
eingebracht, können entsprechende Quelltextzeilen nicht mehr den eigentlichen Erstellern
zugeordnet werden. Bei Projekten, bei denen (zum Beispiel durch die Menge an Quelltext, den
Workflow oder das Projektmanagement o.Ä.) eine rigorose Versionskontrolle unerlässlich ist, stößt
Gobby hier an seine Grenzen [gby2].
Gobby bietet sich zum Rapid Prototyping (schnelles entwickeln von Prototypen) in kleinen
Gruppen an, wobei die Kommunikation der Teilnehmer über einen externen Kanal abgewickelt
werden muss, denn das integrierte IRC-artige Chatsystem ist nicht ausreichend für komplexe und
ausführliche Kommunikation zwischen den Teilnehmern. Die Beschränkung auf Textdateien
Seite 4
reduziert Gobbys Nützlichkeit auf den Bereich der kollaborativen Arbeit an Programmcode o.Ä.
(wo es durch das Vorhandensein integrierten clientseitigen Syntax-Highlightings aber seine Stärken
zeigt).
Gobby kann in jedem TCP/IP basierten Netzwerk, auch ohne WAN-Anbindung, verwendet werden.
Der Client arbeitet sehr ressourcensparend (weniger als 5MB Arbeitsspeicher) und ist für Windows
und Linux verfügbar. Auch der Server arbeitet sehr ressourcensparend (weniger als 10MB
Arbeitsspeicher, selbst bei mehr als 5 Nutzern, sowie geringe CPU-Auslastung). Es ist kein
dedizierter Server notwendig, um den Gobby-Dienst bereitzustellen und so kann bei Bedarf auch
auf einer Desktop-Arbeitsstation eine Sitzung eröffnet werden, ohne dass diese Arbeitsstation
ausgelastet ist.
III. Entferntes, kollaboratives Arbeiten mit Google Docs
„Docs“ ist eine von Google kostenlos2
bereitgestellte Office-Suite, die im
Webbrowser lauffähig ist, wobei alle
Dokumente in den Google Rechenzentren
und nicht auf den Client-PCs gespeichert
werden. Diese Office-Suite beinhaltet eine
Möglichkeit zum Bearbeiten von
Textdokumenten (ähnlich „OOo3 Writer“
oder „Microsoft Word“) , Zeichnungen
(ähnlich „OOo Draw“ oder „Microsoft
Publisher“), Tabellen (ähnlich „OOo Calc“ Abb. 2: Google Docs Dokumentenliste in Firefox 5.0
unter Ubuntu/Gnome3 mit einer Reihe von
oder „Microsoft Excel“) und Präsentationen Dokumenten, Präsentationen und importierten pdf(ähnlich „OOo Impress“ oder „Microsoft Quellen.
PowerPoint“) [glgd1]. Die Funktionalität der im Webbrowser lauffähigen Office-Suite ist bei
Weitem nicht so umfangreich, wie die der anderen etablierteren Suiten, aber durch die Ausführung
und Darstellung im Browser sind die technischen Grenzen auch wesentlich enger gesteckt, als bei
einer klassischem Systemanwendung [glgd2].
2 Zur Verwendung ist der Besitz eines Google-Accounts notwendig
3 OpenOffice.org
Seite 5
Bei Google Docs kann ein Nutzer ein Textdokument erstellen und wie in anderen
Textverarbeitungsprogrammen bearbeiten, exportieren (u.A. pdf) und drucken. Ebenso kann der
Eigentümer dieses Dokuments (ähnlich wie bei Google Maps) andere Google-Nutzer zur
Kollaboration einladen, sowie Dokumentengruppen (ähnlich „Ordner“, siehe Abb. 2 mit mehreren
Dateien, einige mit der Dokumentengruppe „HTWK“) anlegen, Dokumente diesen Gruppen
hinzufügen andere Google-Nutzer für diese Gruppen freigeben.
Nun können der Besitzer und Mitnutzer gleichzeitig oder, da die Sitzung vom GoogleRechenzentrum aus verwaltet wird, unabhängig voneinander ein für sie freigegebenes Dokument
öffnen und das Dokument bearbeiten. Auch wenn der Besitzer selbst nicht an der Sitzung teilnimmt,
kann kollaborativ gearbeitet werden.
Die Nutzer können, ähnlich wie bei Gobby, den Inhalt live bearbeiten. Welche Inhalte von welchem
Nutzer eingebracht und bearbeitet werden, wird jedoch nicht farblich hinterlegt und ist, gerade
wenn die Nutzer nicht gleichzeitig an dem Dokument arbeiten, nicht direkt nachzuvollziehen. Da es
sich jedoch (anders als bei Gobby) um Dokumente an Stelle einfacher Textdateien handelt, besteht
bei Textfärbung oder farblicher Hinterlegung (als Hinweis auf den Ersteller) durchaus
Verwechslungsgefahr mit wirklicher Textgestaltung.
Die Verzögerung in der Sichtbarkeit der Änderungen innerhalb der Dokumente ist für alle
gleichzeitig arbeitenden Nutzer, abhängig von der spezifischen Verbindung, gering. Wenige 100
Millisekunden, oft weniger, sind für Google Docs übliche Verzögerungen.
Beim Bearbeiten der Dokumente ist für alle Nutzer stets der Viewport4 der anderen Nutzer sichtbar,
so ist es überschaubar, welcher Nutzer auf welcher Seite des Dokuments arbeitet. Es gibt einen
eigenen Chat für jedes aktive Dokument, so ist eine übersichtliche Kommunikation gewährleistet,
im Gegensatz zu Gobby, wo es nur einen Chat für eine Sitzung gibt, unabhängig davon, wie viele
Nutzer an wie vielen Dokumenten arbeiten. Wenn diese dokumentenbezogene n:n-Kommunikation
jedoch nicht ausreicht, kann für eine 1:1-Kommunikation auf Google Talk zurückgegriffen werden.
Zur Kontrolle aller Änderungen an den Dokumenten ist außerdem eine vollständige
Revisionshistorie, also eine Liste aller Änderungen, vorhanden und der Besitzer kann das
Dokument auf jeden bisherigen Zustand zurücksetzen.
4 Der für einen Nutzer eines Programms sichtbare Teil des Dokuments oder (allg.) der zu bearbeitenden Datenstruktur.
Dies umfasst nicht die Bedienelemente. Im Webbrowser zum Beispiel der sichtbare Teil der Internetseite.
Seite 6
Google Docs benötigt einen modernen Browser (IE 8, Firefox 4 usw.) und eine Internetverbindung
mit mind. 200kbit/s (EDGE und schneller) Datenrate. Google Docs ist damit nicht von einem
speziellen Betriebssystem abhängig. Browser mit entsprechenden Funktionen sind auf allen
aktuellen, etablierten Betriebssystemen verfügbar.
Google Docs eignet sich aufgrund von fehlendem Syntax-Highlighting5 nicht für kollaboratives
Programmieren sondern nur für übliche Office-Anwendung. Dabei ist Google Docs nicht so
mächtig, wie andere etablierte Office-Suiten, aber eine durchaus brauchbare Alternative für den
Heimgebrauch. Das Fehlen erweiterter Diagrammfunktionen, Import- und Exportfunktionen,
Makros, Datenbankanbindungen und das Fehlen der Möglichkeit zur Einbindung spezieller Fonts
machen Google Docs für den Gebrauch im professionellen Bereich ungeeignet. Die
Kollaborationsfunktionen sind trotzdem zukunftsweisend und es ist davon auszugehen, dass auch
die klassischen Office-Suiten in naher Zukunft mit ähnlichen Funktionen aufwarten werden6.
IV. Kollaboratives und unabhängiges Arbeiten an einer
Arbeitsstation mit MPX
Multi-Pointer X [mpx1] ist eine Erweiterung des X-Servers X.Org. In der normalen7 Version des XServers gibt es jeweils nur einen Kanal für die Eingabe durch ein Zeigegerät (Maus, Trackpad,
Touchpad, Touchscreen usw.) und einen Kanal für die Eingabe durch eine Tastatur. An einen
Computer können zwar mehrere der genannten Eingabegeräte angeschlossen werden, aber so lange
diese Geräte die selbe Sitzung ansteuern, überlagern sich die Eingaben der Geräte. Bei zwei
vorhandenen Mäusen, die sich in entgegengesetzte Richtungen bewegen, würde der Mauscursor
also nur wackeln, aber keine signifikante Bewegung in eine Richtung machen. Da es auch nur einen
Cursor gibt, kann auch immer nur ein Objekt der graphischen Oberfläche den Eingabefokus
besitzen und somit würde das Anschließen einer weiteren Tastatur nur bewirken, dass Nutzer
gleichzeitig nur ein und das selbe Eingabefeld benutzen können.
Es können durch die Verwendung mehrerer Monitore mit separaten X-Session auch separate
Gruppen von Eingabegeräten verwendet werden. Da es sich um unabhängige X-Sessions handelt
(die nur „zufällig“ auf der selben Maschine ausgeführt werden), können die Nutzer jedoch nicht
5 Siehe Kapitel II
6 Microsoft SharePoint Server beinhaltet bereits ähnliche Funktionalität [mssp]
7 Mit den als Voreinstellung gesetzten Compilerflags kompiliert bzw. von bekannten Distributionen wie Ubuntu,
Debian, Fedora usw. ausgelieferten Binärpaketen
Seite 7
wesentlich besser interagieren, als an separaten Arbeitsstationen, da sich die Nutzer nur ein
gemeinsames Dateisystem teilen (dies ist aber auch, abhängig von der Konfiguration, bei der
Verwendung von Thin Clients der Fall).
Durch die Verwendung von MPX können mehrere Eingabegeräte (z.Bsp. eine Maus und eine
Tastatur) zu einer Gruppe zusammengefasst werden. Diese Gruppe von Eingabegeräten teilt sich
jeweils einen Eingabecursor, damit sich die Eingaben der Eingabegeräte, wie bei der Verwendung
eines Cursors, nicht überlagern [mpx2]. Diese verschiedenen Cursor, die sich zum Beispiel durch
Farbe unterscheiden8 (die exakte abhängig vom Fenstermanager [mcwm]), können unterschiedliche
Applikationen in der selben X-Session (auf einem oder mehreren Ausgabegeräten) bedienen.
Applikationen deren Funktionalität oder Umsetzung nicht auf der Annahme beruht, dass es nur
einen Cursor gibt, funktionieren hierbei problemlos auch ohne Änderungen.
Die Konfiguration eines solchen Systems ist umfangreich, da die komplexen X-ServerKonfigurationsdateien von Hand geschrieben werden müssen (übliche Desktop-Konfigurationen
mit einem Monitor und einem Satz Eingabegeräte, wie Maus u. Tastatur, werden durch diverse
Werkzeuge zur automatischen Konfiguration erstellt). Außerdem muss das System einen X-Server
verwenden, was die Anwendbarkeit auf Unix-Systeme beschränkt.
V. Screen-Sharing per VNC
VNC (Virtual Network Computing) ist eine graphische Desktop-Sharing-Technologie. VNC benutzt
hierbei das remote framebuffer-protocol, welches auf dem sog. „Pixel-Level“ (hierbei wird der
Bildschirminhalt als eine Bitmap-Grafik übertragen) arbeitet [vnc1].
Der VNC-Server stellt hierbei für die Clients ein Interface bereit, um schreibend auf die
Schnittstellen der Eingabegeräte Maus und Tastatur des Servers zuzugreifen. Außerdem sendet der
VNC-Server das ausgerenderte, also von der Grafikkarte erstellte, Monitorbild an die Clients zurück
(siehe Abb. 3, Monitorbild des Windows 7 Hosts im VNC-Client sichtbar).
Da das Monitorbild als Bitmap (je nach Konfiguration komprimiert und nur in Teilbildern) an die
Clients gesendet wird, ist das Datenaufkommen im Vergleich zu anderen Systemen zum DesktopSharing höher. RDP9 zum Beispiel sendet an die verbundenen Clients auch Grafikprimitive
8 Die Art der Darstellung des Unterschieds der Cursor ist Sache des Fenstermanagers. Der projekteigene
experimentelle Fenstermanager MPWM (Multi-Pointer Window-Manager) unterscheidet die Eingabecursor durch
verschiedene Farben und färbt die Fenster, in denen der Eingabecursor Eingabefokus besitzt, in der Farbe des
Cursors.
9 Remote Desktop Protocol, [msdn1]
Seite 8
(Bitmap-Cache-Objekte, Textobjekte), um das Datenaufkommen zu verringern. Durch das hohe
Datenaufkommen sind Frameraten auch in 100Mbit-Lan-Bereich niedrig (teilw. weniger als 5
Bilder pro Sekunde) und für Multimedia-Anwendungen völlig ungeeignet.
Da das Monitorbild als PixelObjekt (Bitmap) übertragen wird,
skaliert dieses System auch
schlecht auf Darstellungsgeräte mit
hoher Auflösung (1080p, 2k, 4k
und mehr), da das
Datenaufkommen mit der Anzahl
der Pixel im Darstellungsbereich
(in Abhängigkeit von der
Komprimierung) entsprechend
zunimmt.
Abb. 3: Windows 7-Desktop (1080p) mit TightVNC als Server
auf Ubuntu Linux mit Vinagre [gnmvnc] als VNC Client
dargestellt
Ein weiteres Problem beim Screen-Sharing mit VNC ist, dass sich alle Nutzereingaben gegenseitig
überlagern. Das System ist dann ähnlich problembehaftet gleichzeitig gemeinsam nutzbar, wie
wenn mehrere Eingabegeräte an die selbe Arbeitsstation angeschlossen werden (ohne MPX oder
ähnliche Konfiguration).
Es besteht jedoch die Möglichkeit, VNC und MPX zu verbinden [printf1]. x11vnc-multiptr ist ein
VNC-Server für X-Server mit aktiviertem Multi-Pointer-Support. Hierbei bekommen alle mit dem
Server verbundenen VNC-Nutzer eine eigene Gruppe von virtuellen Eingabegeräten (Maus,
Tastatur) am MPX-gestützten System zugeordnet. Jeder Nutzer kontrolliert so einen eigenen Cursor
auf dem gemeinsamen Bildschirm.
So können mehrere Nutzer gleichzeitig auf verschiedene Applikationen des Servers zugreifen, die
Framerate nimmt hierbei im Gegensatz zur Einzelnutzung noch weiter ab, da das Monitorbild an
mehrere Nutzer gleichzeitig versendet werden muss. Da viele Nutzer gleichzeitig Applikationen auf
dem selben Display nutzen und dafür der entsprechende Platz nötig ist, muss das verwendete
Display in der Regel sehr groß (1080p und größer) sein. Das Datenaufkommen nimmt durch die
höhere Displaygröße, im Gegensatz zur Einzelplatznutzung, entsprechend zu.
MPX über VNC ist in seiner Nutzbarkeit vornehmlich durch die Nachteile von VNC beschränkt
und durch die niedrige Framerate und hohes Datenaufkommen für langsame Netze (weniger als
3Mbit Upstream beim Server) kaum geeignet. Da der Server ein ausgerendertes Monitorbild zur
Seite 9
Verfügung stellt, muss er auch eine Grafikkarte (und ein entsprechendes Anzeigegerät in der
Zielauflösung) besitzen und es muss eine graphische Oberfläche mit allen ihren Komponenten
bereit gestellt werden. Dies ist in einer Server-Umgebung in der Regel nicht vorgesehen und daher
schwer realisierbar.
VI. Möglichkeiten des Broadway-Interface in GTK+3.2
GTK+ ist eine Komponentenbibliothek
zum Erstellen von graphischen
Oberflächen. GTK+ ist für X-Server
unter Linux/Unix verfügbar, aber auch
für Windows und Mac OS X. Dieses
Kapitel beschäftigt sich mit dem neuen
Broadway-Interface, welches
Abb. 4: Gnome Taschenrechner per Broadway in Firefox
5 unter Debian/Gnome3 – Quelle: Alexander Larsson
verfügbar sein wird (Windows und Mac
[gnmelrssn]
OS X wird hierbei außer Acht gelassen). Das Broadway-Interface ist noch in einer Phase der
voraussichtlich in GTK+3.2 für Linux
Entwicklung und so sind einige Features instabil.
In der Regel wird GTK+ nur mit der Option --enable-x11-backend kompiliert [gtk1]. Dies
ermöglicht es GTK+-Anwendungen über das gemeinsame GTK+-Interface mit dem X-Server zu
kommunizieren und entsprechende graphische Oberflächen darstellen zu lassen. Kompiliert man die
aktuelle10 git-master-branch (der experimentelle Entwicklungszweig) mit der Option --enablebroadway-backend (das X11-Backend muss auch aktiviert sein) besteht die Möglichkeit, eine
Applikation mit GDK_BACKEND=broadway anwendung& mit Broadway als Backend zu
starten [gnme1]. Damit wird nicht der X-Server angesteuert, sondern ein Webserver gestartet, der
eine HTML5-Seite generiert, die genau die gestartete Applikation enthält. Die Anwendung lässt sich
dann wie gewohnt steuern, nur, dass sie sich im Browser befindet (siehe Abb. 4, Gnome
Taschenrechner im Browser).
Zur Kommunikation zwischen Server und Client wird die HTML5-Technologie Websockets
genutzt. Die Websockets-Funktionalität muss zur Zeit auf Grund von möglichen Sicherheitslücken
in Firefox manuell aktiviert werden [hse1]. So können, auch ohne X-Server (mit X-Forwarding)
graphische Applikationen auf einem entfernten Server ausgeführt und lokal angezeigt werden. Die
Verbindung ist in der aktuell verfügbaren Version eine 1:1-Verbindung, sodass eine Anwendung nur
10 Stand Juli 2011
Seite 10
von einem Client gesteuert werden kann. Es gibt jedoch in der Websockets-Technologie keine
grundlegende Einschränkung, die Gegen die Umsetzung einer 1:n-Verbindung sprechen, sodass
mehrere Clients zur gleichen Zeit eine Anwendung steuern können.
Da für die entfernten Nutzer kein ssh-Zugang notwendig ist, gibt es potentiell einen Angriffsvektor
weniger, da die Nutzer der Applikation keinen User-Account auf dem Serversystem haben müssen.
Ein Passwortschutz kann über http-Authentifikation bereit gestellt werden. Durch die Verwendung
des Broadway-Interface können auch verschiedenste Applikationen „on Demand“ bereit gestellt
werden. Verschiedene Geschäftsmodelle und Anwendungen sind an dieser Stelle denkbar.
VII. Zusammenfassung und Beispielanwendung
Die Betrachtung hat gezeigt, dass es verschiedene spezialisierte Möglichkeiten zum kollaborativen
Arbeiten gibt, die alle ihre Grenzen und Limitierungen haben. Keines der Programme kann für alle
möglichen Nutzungsfälle eine ganzheitliche Lösung bieten. Gobby (Kapitel II) ist stark auf das Feld
der Softwareentwicklung und Programmierung beschränkt, hat dort aber einen festen Platz. Google
Docs (Kapitel III) ist für den Gebrauch im professionellen Bereich – im Gegensatz zu anderen
Office-Suiten – bei Weitem nicht mächtig genug, kann aber, durch das von Google durchgeführte
Hosting, mit minimalen technischen Voraussetzungen eingesetzt werden. VNC (Kapitel V) ist durch
die hohe benötigte Datenrate (trotz niedriger Framerate) für viele Anwendungsgebiete nicht nutzbar.
Dadurch, dass vollständige Monitorbilder übertragen werden, eignet sich VNC auch mit MPX
(Kapitel IV) nicht für effektives kollaboratives Arbeiten. Mit Broadway-Interface (Kapitel VI) sind
jedoch verschiedene weitere Anwendungsmöglichkeiten für bestehende Software denkbar.
Zum Beispiel: Diverse Application-Server stellen über das Broadway-Backend verschiedene (teils
stark rechenintensive) Anwendungen bereit. Diese Application-Server können sich gemeinsame
Netzwerkfestplatten und Laufwerke teilen, um die Interoperabilität und Datenverfügbarkeit der
verschiedenen Systeme zu gewährleisten.
Nutzer können von zu Hause oder unterwegs mit einem Endgerät mit einem HTML5-fähigen
Browser auf Daten und Applikationen zugreifen und so zum Beispiel auch unterwegs vollwertige
Desktop-Applikationen nutzen. Die Art des darunterliegenden Geräts oder das Betriebssystem
spielen hier nur eine untergeordnete Rolle. Im Desktop-Bereich ist außerdem Verwendung von
minimalen Systemumgebungen, wie ASUS Express Gate [asusexp], denkbar, welche nur die
Browserfunktionalität besitzen und in weniger als 10 Sekunden gebootet sind. Wenn nur die
Browserfunktionalität benötigt wird, gibt es keine Notwendigkeit, in ein vollwertiges
Betriebssystem zu booten.
Seite 11
Neben individuellen Arbeitsstationen (oder Thin Clients) sind Gruppenarbeitsstationen mit
mehreren Bildschirmen und Eingabegeräten (z.Bsp. Jeweils 4) in separaten X-Sessions denkbar.
Diese Gruppenarbeitsstationen müssen nur die Netzwerkverbindung zu den Application-Servern
halten und entsprechende HTML5-fähige Browser zur Verfügung stellen. Rechenzeit wird an diesen
Stationen, bis auf das Bereitstellen der Browser und der graphischen Oberflächen nicht benötigt. Da
der Browser das gemeinsame universelle Interface ist, wird außerdem die Konfiguration und
Administration erleichtert.
Durch die Verwendung des Browsers als universelle Schnittstelle, kann die darunterliegende Ebene
(Betriebssystem, Hardware) heterogener sein, als bisher. Auch die automatische Softwaresteuerung
kann durch den Zugriff auf Steuerelemente über den von Broadway erstellten DOM11-Baum
vorgenommen werden. Dies lässt sich leicht mit JavaScript implementieren und benötigt keine
vertieften Betriebssystemkenntnisse, um Zugriff auf die Komponenten der graphischen Oberfläche
zu erhalten.
Viele Desktop-Applikationen können so auf neue Art und Weise auf verschiedene Arten und Weisen
zugänglich gemacht werden.
11 Document Object Model
Seite 12
VIII. Abbildungsverzeichnis
Abb. 1: Gobby unter Ubuntu/Gnome3 - Editieren einer php-Datei mit entspr. Syntax-Highlighting. 3
Abb. 2: Google Docs Dokumentenliste in Firefox 5.0 unter Ubuntu/Gnome3 mit einer Reihe von
Dokumenten, Präsentationen und importierten pdf-Quellen................................................................5
Abb. 3: Windows 7-Desktop (1080p) mit TightVNC als Server auf Ubuntu Linux mit Vinagre
[gnmvnc] als VNC Client dargestellt...................................................................................................9
Abb. 4: Gnome Taschenrechner per Broadway in Firefox 5 unter Debian/Gnome3 – Quelle:
Alexander Larsson [gnmelrssn]..........................................................................................................10
IV. Quellen
•
[asusexp] - “ASUS Express Gate”, ASUSTeK Computer Inc., Juli 2011,
http://expressgate.asus.com/
•
[avahi] - “AboutAvahi”, Avahi Project Group, Juli 2010,
http://avahi.org/wiki/AboutAvahi#Details
•
[aws] - “Amazon Elastic Compute Cloud (Amazon EC2)”, Amazon.com Inc., 2011,
http://aws.amazon.com/de/ec2/
•
[crn1] - “Amazon Cloud Revenue Could Exceed $500 Million In 2010: Report”, Andrew R
Hickey, August 2010, http://www.crn.com/news/applications-os/226500204/amazon-cloudrevenue-could-exceed-500-million-in-2010-report.htm
•
[drgs] - “Thomson Scientific Takes a Fresh Look at Multiauthor Papers”, drugs.com,
November 2007, http://www.drugs.com/clinical_trials/thomson-scientific-takes-fresh-lookmultiauthor-papers-2810.html
•
[gby] - “Gobby”, 0x539 dev group, März 2011, http://gobby.0x539.de
•
[gby1] - “[Release] Gobby 0.4.90, libinfinity 0.1.0”, Armin Burgmeier, Oktober 2008,
http://article.gmane.org/gmane.network.obby.user/284
•
[gby2] - “Testimonials”, Jamey Sharp u. Josh Triplett, Mai 2007,
http://gobby.0x539.de/trac/wiki/Testimonials
•
[gbydwn] - “Download – Gobby”, 0x539 dev group, März 2011,
http://gobby.0x539.de/trac/wiki/Download
•
[glgd1], „Google Docs Tour“, Google Inc., 2011, http://www.google.com/google-ds/tour1.html
•
[glgd2], „How Google Docs Works“, Jonathan Strickland, 2008
http://communication.howstuffworks.com/google-docs.htm
Seite 13
•
[gnme1] - “Gtk+ HTML backend update”, Alexander Larsson, März 2011,
http://blogs.gnome.org/alexl/2011/03/15/gtk-html-backend-update/
•
[gnmelrssn] – GTK+ Broadway screencast, Alexander Larsson, März 2011,
http://www.gnome.org/~alexl/broadway-screencast.webm
•
[gnmvnc] - “Vinagre”, David King, Juli 2011, http://projects.gnome.org/vinagre/
•
[gtk1] - “Compiling the GTK+ libraries”, The GNOME Project, 2011,
http://developer.gnome.org/gtk3/unstable/gtk-building.html
•
[hse1] - “WebSockets in Firefox 4 wegen Lücke im Protokolldesign deaktiviert”, Daniel
Bachfeld, Dezember 2010, http://www.heise.de/security/meldung/WebSockets-in-Firefox-4wegen-Luecke-im-Protokolldesign-deaktiviert-Update-1150157.html
•
[mcwm] - “Multi-Cursor Window Manager”, Kai Li research group, März 2006,
http://multicursor-wm.sourceforge.net/
•
[mpx1] - “MPX: Multi-pointer X”, Wearable Computer Lab, 2010,
http://wearables.unisa.edu.au/projects/mpx/
•
[mpx2] - “compiz with mpx support”, Peter Hutterer, Juli 2008, http://who-t.blogspot.com/
•
[msdn1] - “Remote Desktop Protocol”, Microsoft Developer Network, Juli 2011,
http://msdn.microsoft.com/en-us/library/aa383015.aspx
•
[mssp] - “Leistungsvermögen”, Microsoft Corporation, 2011,
http://sharepoint.microsoft.com/de-at/product/capabilities/Seiten/default.aspx
•
[printf1] - “Multi-pointer Remote Desktop”, Chris Ball, Januar 2009,
http://blog.printf.net/articles/2009/01/26/multi-pointer-remote-desktop
•
[vnc1] - “Introduction to TightVNC”, TightVNC, 2010, http://www.tightvnc.com/intro.php
Seite 14