Mario Wenzel. Application-Sharing Übersicht und Beispielanwendung

Transkript

1 Hochschule für Technik, Wirtschaft und Kultur Leipzig (FH) Fachbereich Informatik, Mathematik, Naturwissenschaften Mario Wenzel 10MIB2 Application-Sharing Übersicht und Beispielanwendung Juli 2011

2 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 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 Desktop- System 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

3 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 Gobby- Projekt 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 Gobby benutzte bis zur Version php-datei mit entspr. Syntax-Highlighting (Oktober 2008) das Protokoll obby und seitdem die projekteigene Infinote-Bibliothek (libinfinity) [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 Server 1 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

4 Ä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

5 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 kostenlos 2 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 OOo 3 Writer oder Microsoft Word ), Zeichnungen (ähnlich OOo Draw oder Microsoft Publisher ), Tabellen (ähnlich OOo Calc oder Microsoft Excel ) und Präsentationen (ähnlich OOo Impress oder Microsoft 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]. Abb. 2: Google Docs Dokumentenliste in Firefox 5.0 unter Ubuntu/Gnome3 mit einer Reihe von Dokumenten, Präsentationen und importierten pdf- Quellen. 2 Zur Verwendung ist der Besitz eines Google-Accounts notwendig 3 OpenOffice.org Seite 5

6 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 Google- Rechenzentrum 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 Viewport 4 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

7 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-Highlighting 5 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 werden 6. 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 normalen 7 Version des X- Servers 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

8 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 unterscheiden 8 (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-Server- Konfigurationsdateien 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 Desktop- Sharing höher. RDP 9 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

9 (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 Pixel- Objekt (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. 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. Abb. 3: Windows 7-Desktop (1080p) mit TightVNC als Server auf Ubuntu Linux mit Vinagre [gnmvnc] als VNC Client dargestellt 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

10 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 voraussichtlich in GTK+3.2 für Linux 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 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 aktuelle 10 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

11 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

12 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 DOM 11 -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

13 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, [avahi] - AboutAvahi, Avahi Project Group, Juli 2010, [aws] - Amazon Elastic Compute Cloud (Amazon EC2), Amazon.com Inc., 2011, [crn1] - Amazon Cloud Revenue Could Exceed $500 Million In 2010: Report, Andrew R Hickey, August 2010, [drgs] - Thomson Scientific Takes a Fresh Look at Multiauthor Papers, drugs.com, November 2007, [gby] - Gobby, 0x539 dev group, März 2011, [gby1] - [Release] Gobby , libinfinity 0.1.0, Armin Burgmeier, Oktober 2008, [gby2] - Testimonials, Jamey Sharp u. Josh Triplett, Mai 2007, [gbydwn] - Download Gobby, 0x539 dev group, März 2011, [glgd1], Google Docs Tour, Google Inc., 2011, [glgd2], How Google Docs Works, Jonathan Strickland, Seite 13

14 [gnme1] - Gtk+ HTML backend update, Alexander Larsson, März 2011, [gnmelrssn] GTK+ Broadway screencast, Alexander Larsson, März 2011, [gnmvnc] - Vinagre, David King, Juli 2011, [gtk1] - Compiling the GTK+ libraries, The GNOME Project, 2011, [hse1] - WebSockets in Firefox 4 wegen Lücke im Protokolldesign deaktiviert, Daniel Bachfeld, Dezember 2010, wegen-luecke-im-protokolldesign-deaktiviert-update html [mcwm] - Multi-Cursor Window Manager, Kai Li research group, März 2006, [mpx1] - MPX: Multi-pointer X, Wearable Computer Lab, 2010, [mpx2] - compiz with mpx support, Peter Hutterer, Juli 2008, [msdn1] - Remote Desktop Protocol, Microsoft Developer Network, Juli 2011, [mssp] - Leistungsvermögen, Microsoft Corporation, 2011, [printf1] - Multi-pointer Remote Desktop, Chris Ball, Januar 2009, [vnc1] - Introduction to TightVNC, TightVNC, 2010, Seite 14