Docstoc

widex

Document Sample
widex Powered By Docstoc
					                                                                              CONFIDENTIAL                                               1 (18)
                                                                              DRAFT
INdT
Elvis Pfützenreuter                                                           24.02.2006
Rosfran Borges
Flávio Oliveira




Widex Remote UI Architecture for Linux
ARCHITECTURE OF WIDEX REMOTE UI SERVER AND RENDERER PROTOTYPES FOR
LINUXTABLE OF CONTENTS

Table of Contents.................................................................................................................................. 2
1. Introduction ....................................................................................................................................... 6
2. Technology Background .................................................................................................................... 6
   2.1 UPnP Remote UI ......................................................................................................................... 6
   2.2 WideX framework ........................................................................................................................ 6
   2.3 LRDP protocol ............................................................................................................................. 7
   2.4 BEEP protocol ............................................................................................................................. 7
   2.5 GTK+ .......................................................................................................................................... 7
   2.6 Hildon .......................................................................................................................................... 7
   2.7 Glade .......................................................................................................................................... 7
   2.8 WideX Sync ................................................................................................................................ 7
   2.9 REX – Remote Events for XML ................................................................................................... 8
3. GENERAL VIEW ................................................................................................................................ 8
4. SYSTEM DECOMPOSITION VIEW ................................................................................................... 8
   4.1 Diagram notation ......................................................................................................................... 8
   4.2 Packages .................................................................................................................................... 9
   4.3 UI Server ..................................................................................................................................... 9
     4.3.1 User-developed UI software ................................................................................................. 10
     4.3.2 Server Control ..................................................................................................................... 10
     4.3.3 UPnP Remote UI Session .................................................................................................... 10
     4.3.4 Cyberlink C UPnP Library: ................................................................................................... 11
     4.3.5 LibXML2 library .................................................................................................................... 11
     4.3.6 LRDP ................................................................................................................................... 11
     4.3.7 Vortex BEEP Library............................................................................................................. 11
     4.3.8 UI file elements server .......................................................................................................... 11
     4.3.9 XML UI update dispatcher .................................................................................................... 12
     4.3.10 XML UI event receiver: ....................................................................................................... 12
     4.3.11 UI update proxy/dispatcher: ................................................................................................ 12
     4.3.12 UI event driver .................................................................................................................... 12
   4.4 UI Client/Renderer ...................................................................................................................... 12
     4.4.1 UPnP Remote UI Session .................................................................................................... 13
     4.4.2 Cyberlink C UPnP Library ..................................................................................................... 13
     4.4.3 LibXML2 library .................................................................................................................... 13
     4.4.4 Glade library ......................................................................................................................... 13
                                                                             CONFIDENTIAL                                              2 (18)
                                                                             DRAFT
INdT
Elvis Pfützenreuter                                                          24.02.2006
Rosfran Borges
Flávio Oliveira


      4.4.5 GTK+ library ......................................................................................................................... 14
      4.4.6 Hildon library ........................................................................................................................ 14
      4.4.7 LDRP ................................................................................................................................... 14
      4.4.8 Vortex BEEP Library............................................................................................................. 14
      4.4.9 UI file elements client ........................................................................................................... 14
      4.4.10 XML UI update receiver/translator ...................................................................................... 14
      4.4.11 XML UI event dispatcher .................................................................................................... 15
      4.4.12 UI update Glade/GTK+ driver ............................................................................................. 15
      4.4.13 GTK+ UI event dispatcher .................................................................................................. 15
5. Runtime view ..................................................................................................................................... 15
   5.1 Session initiation and UPnP ........................................................................................................ 15
   5.2 UI Update initiated in server side ................................................................................................. 16
    5.3 UI update received at client side.................................................................................................. 17
    5.4 UI event initiated in client side ..................................................................................................... 17
    5.5 UI event received at server side .................................................................................................. 18
6. UPnP view ........................................................................................................................................ 19
   6.1 UPnP Server-side UI ................................................................................................................... 19
   6.2 UPnP Client-side UI .................................................................................................................... 19
   6.3 Interaction with the UPnP Session management mechanism ...................................................... 19
7. References ....................................................................................................................................... 21
1.             INTRODUCTION

                   The purpose of this project is to build a prototype implementation of Remote UI based on
                   the WideX [8] framework for Linux, in order to demonstrate that the WideX concepts are
                   feasible for Linux/Glade.

                   Remote UI is a system where the user interface (UI) is rendered in a device different from
                   the device that runs the application logic. Several other systems and protocol exist for this
                   purpose, for example X Window System, VNC etc. WideX distinguishes from these other
                   protocols by two main features: it is XML based, and exchanges higher-level messages.

                   UPnP [1] standards include a Remote UI specification, capable of session and protocol
                   negotiation, even though the details of the actual UI message exchange is left for other
                   protocols – WideX in this project.

                   Analog to UPnP, WideX also delegates the upper level of UI message grammar, as well as
                   the widget set, to the application. In this project, a LRDP-Glade [5] generated XML-schema
                   will fill this role, following the schema defined on the LRDP architecture description [7].

2.                 TECHNOLOGY BACKGROUND

2.1                 UPnP Remote UI

                   The UPnP Remote UI specifications provide a framework for remoting user interfaces
                   between servers and client UPnP devices. The UPnP Remote UI framework supports
                   discovery of remote UI servers and servers. The Remote UI servers consists of the UPnP
                   devices where the applications reside, while the Remote UI clients consists of the UPnP
                   devices where the UI is remoted and receives the interaction from the user that will be
                   communicated back to the Remote UI server. The Remote UI framework also provides the
                   management of the connection between the Remote UI server and client. Thus, the UPnP
                   Remote UI specifications does not mandate the UI protocol that is used for remoting the UI
                                                     CONFIDENTIAL                            3 (18)
                                                     DRAFT
INdT
Elvis Pfützenreuter                                  24.02.2006
Rosfran Borges
Flávio Oliveira


             from the remote UI server to the client and communicating back the user interaction from
             the remote UI client to the server.

             The UPnP Remote UI Server functions in a manner very similar to a UPnP AV Media
             Server Content Directory Service in that it principally exposes Extended Markup Language
             (XML) listings containing URIs that correspond to remote-capable UI applications. An UPnP
             RUI Client device functions in a manner similar to a UPnP AV Media Renderer in that it can
             accept requests from a control point to connect to a specified, remoted user interface. The
             UPnP RUI Client additionally possesses the ability to initiate locally a connection by
             selecting from a listing of UIs pushed to it from a client control point.

             UPnP RUI requires at least one common, peer-to-peer remote transfer communication
             protocol to be supported for basic device interoperability. UPnP does not define the remote
             transfer protocol, therefore, the remote transfer protocol is considered to be “out-of-band”
             with respect to the UPnP device. Once connected, a remoted application and a UPnP RUI
             client device employ the out-of-band communication protocol to transmit UI events and
             updates.

2.2           WideX framework

             WideX framework is the general specification of a Remote UI system. All other components
             – transport, session negotiation, sync language –- fit into WideX's view. It is important to
             mention that, except by XML encoding, WideX does not mandate any particular protocol or
             technology for any of the components. It just specifies the requirements.

2.3           LRDP protocol

             LRDP [7] is a concept remote UI protocol, based on XML, composed of 2 main
             unidirectional channels, one carrying UI events from the renderer and the other carrying UI
             updates to the renderer. More channels may be allowed for special purposes. LRDP is the
             transport layer for WideX that will be implemented by this project. The LRDP specification
             names BEEP as its low-level transport.

             LRDP specifies, at the lowest level, the XML UI messages that can be exchanged between
             server and renderer: uiInitialisation, uiUpdate, uiEvent and uiFragment. Note that children
             of these messages fall out of the scope of LRDP, and may belong to another XML
             namespace.

2.4           BEEP protocol

             BEEP (Blocks Extensible Exchange Protocol) is a generic application protocol kernel for
             connection-oriented, asynchronous interactions [4]. It allows, for example, multiple sub-
             streams running over a single TCP/IP connection. This project aims to use BEEP, but
             LDRP transport may be supplied by simple TCP/IP connections while a suitable
             implementation of BEEP is not found.

2.5           GTK+

             GTK+ (Gimp ToolKit) is a widget set that is the basis of a huge number of free software.
             GUI systems, including the GNOME Desktop Environment.
                                                      CONFIDENTIAL                               4 (18)
                                                      DRAFT
INdT
Elvis Pfützenreuter                                   24.02.2006
Rosfran Borges
Flávio Oliveira


2.6           Hildon

             Nokia's Maemo environment also employs GTK+ as the main widget set, with the Hildon
             extensions that follow a better fit of GTK in a mobile/pen-based UI.

2.7           Glade

             Glade is basically a means of specifying a GTK+ user interface in XML format [5]. It allows
             a certain degree of independence between UI appearance and event handling code e.g.
             allows changing UI without recompiling the program. It also allows RAD (rapid application
             development) in GTK+ since it is easy to load and save interface descriptions in XML,
             while it would be almost impossible to recover the UI from a generated C code.

             In this project, Glade features will be stretched to allow remote UI construction, event
             handling and UI updates. Maemo does include Glade library but, in present version, Glade
             does not support Hildon extensions.

             Glade lends its XML grammar to our UI update protocol, and allows the Remote UI
             software developer to take advantage of most RAD tools available.

2.8           WideX Sync

             WideX Sync is the WideX component that actually carries UI events and updates. It is not
             specified by the time of this document, although it is required that it will be carried by LRDP
             messages. This project must select and implement a XML grammar (that will be based
             upon the Glade XML-Schema) that fits this role. A strong suggestion is the REX grammar.

2.9           REX – Remote Events for XML

             REX is a proposed XML grammar that allows transmission of DOM events. Every event
             specifies a target (using a XPath expression), an event name (some of them are defined by
             REX itself, v.g. DOMNodeInserted, DOMNodeRemoved etc.) and a set of attributes
             (timestamp etc.). REX allows any XML-based object to be updated remotely, be it a SVG
             picture or a XHTML text, or a XML UI description.

             REX resembles XML Patch [9] in some respects; both allow remote manipulation of a XML
             tree, and they use XPath to name the DOM targets. But REX can transmit any event while
             XML Patch is constrained to XML-update events. So we can use REX in both directions of
             the WideX Sync: UI events (that do not change UI tree by themselves) and UI updates.

             But REX does not specify the XML grammar for UI events and updates at highest level.
             This level will be filled by Glade XML grammar.



3.           GENERAL VIEW

             The figure below shows the general view of Linux/Glade/WideX architecture, without
             detailed decomposition.


               Gnome            Glade XML                             Glade XML         Gnome/Glade
              Application      User Interface                        User Interface      UI Renderer




                                Widex Sync                            Widex Sync
                                                   CONFIDENTIAL                           5 (18)
                                                   DRAFT
INdT
Elvis Pfützenreuter                                24.02.2006
Rosfran Borges
Flávio Oliveira




4.           SYSTEM DECOMPOSITION VIEW

4.1           Diagram notation

             The decomposition diagrams will use some UML elements and filling colors, The following
             figure shows the meaning of every element in those diagrams:




4.2           Packages

             The general component segregation in packages, both in Remote UI server and
             client/renderer, are modeled after the WideX framework subsystems: session initiation,
             WideX Sync and Transport, as shown in the figure below:
                                                     CONFIDENTIAL                             6 (18)
                                                     DRAFT
INdT
Elvis Pfützenreuter                                  24.02.2006
Rosfran Borges
Flávio Oliveira




             The three yellow packages have some or all components that will be developed in this
             project. To a certain extent, the development of these packages may be run in parallel,
             since dependencies between them are weak. For example, WideX transport may be
             supplied by a simple TCP/IP channel in early stages of WideX Sync development, and
             Session Initiation has no dependency to other packages.

             The fourth (white) package of the diagram, not to be developed in this project, is the set of
             Maemo libraries. Besides running correctly in a standard Linux distribution, this project
             aims to run in Maemo platform. This is an important thing to take into account when
             choosing libraries v.g. a library offered by Maemo takes precedence over a non-Maemo
             library with the same functionality.


4.3           UI Server

             Expanding the former diagram to show the packages' components for the Remote UI
             server leads to the following diagram:
                                                       CONFIDENTIAL                               7 (18)
                                                       DRAFT
INdT
Elvis Pfützenreuter                                    24.02.2006
Rosfran Borges
Flávio Oliveira




4.3.1         User-developed UI software

             This component is supplied by the framework user; it is the UI application itself.

             The aim of this project is to allow the developer to create and test a GTK+/Glade program
             as a local GUI software, and then porting to the Remote UI server APIs with the least effort
             possible.

4.3.2         Server Control

             The server control component is responsible to drive the UPnP Remote UI and implement
             policies (e.g. allowing only one client at a time for a given user application).

             Once the session is initiated, the server fork()s a new subprocess for that client, so all other
             components do not have to care about the multiplicity of clients using the same application.

             The user program will only have to worry about concurrent sessions to the same extent as
             it would worry in local GUI applications e.g. synchronizing/locking access to files etc.

             The server control exports APIs so the user application can register itself in the framework.

4.3.3         UPnP Remote UI Session

             This component implements the UPnP Remote UI features that are part of UPnP standard
             but are not present in Cyberlink UPnP library.

             This component will contain both client and server functionality. It is intended to be general
             library or component (not tied to this project), so it will be implemented with this
             requirement in mind.
                                                       CONFIDENTIAL                             8 (18)
                                                       DRAFT
INdT
Elvis Pfützenreuter                                    24.02.2006
Rosfran Borges
Flávio Oliveira



             At the server side, driven by the server control, this component is responsible by
             negotiating the UI grammar and channel to be set up between server and renderer. Once
             the session is up, its functions are done.

             This component is present both at server and client, and it is further decomposed in the
             section 6 of this document.

4.3.4         Cyberlink C UPnP Library:

             CyberLink for C offers a complete support to the UPnP technology, and was developed
             specifically for Linux embedded devices. It is going to be included in Maemo platform in a
             future version.

             This component is present both at server and client.

4.3.5         LibXML2 library

             A DOM and XPath capable XML library is necessary. Maemo offers three XML libraries:
             libxml, libxml2 and expat. This project chooses libxml2 since it offers XPath.

             This component is present both at server and client.

4.3.6         LRDP

             LRDP protocol is the transport layer for the WideX framework. This component implements
             this protocol and offers APIs to send/receive messages.

             This component is intended to be a general library or module (not tied to this project), and
             will implement both client and server functionality, albeit the server will only use server-side
             APIs.

             This component is present both at server and client.


4.3.7         Vortex BEEP Library

             LRDP makes use of the BEEP protocol. Maemo offers no BEEP library at present, so this
             project chose to use Vortex library [10], which is LGPL-licensed.

             This component is present both at server and client.

4.3.8         UI file elements server

             Some UI elements, like icons, PNG pictures etc. are stored in files and are just pointed (not
             copied) by Glade XML UI descriptions. In a remote UI, it is almost certain that the files will
             not exist at client side (even standard GTK+ icons may not be all there).

             These file pointers must be translated to URLs at server-side. Client will use the URLs to
             fetch those files using a separate LRDP channel.
                                                      CONFIDENTIAL                              9 (18)
                                                      DRAFT
INdT
Elvis Pfützenreuter                                   24.02.2006
Rosfran Borges
Flávio Oliveira


             The UI file elements server component is responsible to serve those files, and translate
             local files into URLs for the UI update dispatcher.


4.3.9         XML UI update dispatcher

             This component translates UI updates to REX XML requests. It has no direct
             communication with user-provided software, neither offers APIs for the user.

4.3.10        XML UI event receiver:

             Decodes REX UI events and forwards the data to the UI event driver component.

4.3.11        UI update proxy/dispatcher:

             This component creates proxy widgets. i.e. objects that have the same interface as GTK+
             widgets but just forward UI update requests to the XML UI update dispatcher. The API
             offered by this component for the client application will be as compatible with GTK+ as
             possible, ideally demanding only a change of header files and recompilation.

             If the GTK+ object system had introspection, we could generate the proxy objects on the
             fly, and new widgets of future GTK+ versions would be automatically suported. But GTK+
             has no introspection (albeit it is planned in the future), so all proxy classes must be defined
             in advance.

             In order to have all classes without having to create them from scratch, this project will use
             a technique from PyGTK (Python bindings for GTK), that generates Python classes semi-
             automatically based on GTK+ header files. We will use PyGTK code generator and its
             definitions to generate as much code as possible, but many functions still need to be hand
             coded.

             This project aims to support almost all GTK+ classes offered by Glade 2.12. Some classes,
             like DrawingArea (Canvas) will not be supported due technical limitations and others like
             IconView, TreeView and TextView due complexity and time constraints. User-defined
             widgets e.g. subclasses of GTK+ widgets defined in the application, will not be supported,
             because a) such widgets could not be remoted in runtime, because there is no
             introspection; b) the widget does not exist at client side.

4.3.12        UI event driver

             Receives decoded UI events from XML UI event module, and calls back the user
             application handler accordingly.

             This component offers APIs to register the callbacks, and is responsible by keeping the list
             of handlers so the UI events can find their way back to the user application.


4.4           UI Client/Renderer
                                                     CONFIDENTIAL                             10 (18)
                                                     DRAFT
INdT
Elvis Pfützenreuter                                  24.02.2006
Rosfran Borges
Flávio Oliveira




4.4.1         UPnP Remote UI Session

             This component has been described at section 4.3.3.

4.4.2         Cyberlink C UPnP Library

             This component has been described at section 4.3.4.

4.4.3         LibXML2 library

             This component has been described at section 4.3.5.

4.4.4         Glade library

             Implements the XML-based UI description for GTK+, and its grammar is used in UI update
             messages. Initial prototype will support, a priori, almost all available GTK widgets that can
             expressed by Glade XML, with exception of those listed in 4.3.11.

             Maemo's Hildon extension is a class of widgets that Glade does not support. To circumvent
             this, we plan to employ a technique present in PyMaemo Glade bindings [11]: parse the
             XML and translate some elements to Hildon elements transparently. For example, the
             Glade regular menu is translated to the Hildon menu, so the user may use Glade RAD tools
                                                     CONFIDENTIAL                             11 (18)
                                                     DRAFT
INdT
Elvis Pfützenreuter                                  24.02.2006
Rosfran Borges
Flávio Oliveira


             for Maemo without much prejudice. (It is perfectly possible that Maemo's libglade itself will
             implement such functionality in future, freeing us - and PyMaemo - from doing this
             translation). However due time constraints, this will be postponed to further versions of
             implementation.

             LRDP is described by a XML schema, while Glade XML grammar is not. In order to check
             the XML messages, a schema is necessary. A Glade/XML schema may have to be written
             along with this prototype. After that, it must to be generated a third schema, which will be
             made with the following 2 steps: 1) parsers the newly generated-GladeXML schema, and
             get the meaning structures we must to use; 2) get these selected GladeXML schema-
             structures, and put them in the LRDP schema syntax. The parsing of the GladeXML-
             schema will be necessary, because restrictions may occur with some of the Glade
             “widgets” XML descriptions [see 4.3.11, for some Glade “widgets” restrictions on the Widex
             architecture]. This new LRDP-Glade schema will be used by this architecture.

4.4.5         GTK+ library

             GTK+ is a widely used widget set, and it is the official Maemo widget set.

4.4.6         Hildon library

             Hildon is a GTK+ extension that makes it suitable for pen-based, limited screen size
             mobile devices.

             Accommodation of Hildon widgets in Glade XML descriptions is a problem; see item 4.4.4
             for details.

4.4.7         LDRP

             This component has been described at section 4.3.6.

4.4.8         Vortex BEEP Library

             This component has been described at section 4.3.7.

4.4.9         UI file elements client

             When an XML UI update is received, it may refer to element files, like icons and pictures.
             This component is responsible by fetching such files from the server, translating the XML
             URLs to local file names, and managing a cache of these files.

4.4.10        XML UI update receiver/translator

             Receives the UI update messages from client, makes the necessary translations (URLs to
             local files, Hildon components, widget names etc.) and sends decoded data to the UI
             update driver.

             It is an open question whether this component will have to keep an updated XML “clone”
             copy of the UI tree (most probably, yes), in order to do its duty, since Glade offers no way
             to export the current widget tree in XML (although it allows to walk the bare GTK+ widget
             tree).
                                                      CONFIDENTIAL                             12 (18)
                                                      DRAFT
INdT
Elvis Pfützenreuter                                   24.02.2006
Rosfran Borges
Flávio Oliveira


             XPath may specify that only an attribute of the widget, instead of the whole widget, is to be
             updated. In this case, this module should pass this information to UI update driver, so the
             last can optimize out unnecessary recreation of widgets.




4.4.11        XML UI event dispatcher

             Receives UI event data from the GTK+ UI event dispatcher and encodes to XML.

4.4.12        UI update Glade/GTK+ driver

             This is the most critical component of this project; it gets UI update requests and applies
             them to the Glade/GTK+ widget tree, so the changes can be seen and felt by the human
             user.

             UI updates in Glade are possible with pre-existing features (i.e. without patching Glade),
             although it is not trivial, since Glade provides no easy-to-use feature to make partial UI
             updates based on XML events. In this project scope, application itself must interpret XML
             events and manipulate GTK+ widget tree accordingly.

             Of course, this project may be a basis to spawn other projects in the future, in order to
             integrate XML update handling into Glade itself, offloading Remote UI applications from this
             task.

4.4.13        GTK+ UI event dispatcher

             Implements the proxy/stub event handlers that are directly called by GTK+ event system.
             Events are translated to the original, server-provided name, and then sent down to XML UI
             event dispatcher.


5.           RUNTIME VIEW

             This section describes the general runtime workflow, helped by simple sequence diagrams.

5.1           Session initiation and UPnP

             Widex framework treats session negotiation as a “black box” handled completely outside
             LRDP. Negotiation includes choosing the XML UI grammar that will be used between
             server and renderer.

             The role of UPnP in this RUI system is to fill this black box. Once the session is on, all RUI
             communication runs outside UPnP modules, so it is possible to include a “direct”
             communication mode (e.g. allowing the renderer to specify the server IP via command line)
             to make RUI debugging easier and independent of UPnP debugging.

             Further UPnP information is given in section 6.

5.2           UI Update initiated in server side
                                                     CONFIDENTIAL                           13 (18)
                                                     DRAFT
INdT
Elvis Pfützenreuter                                  24.02.2006
Rosfran Borges
Flávio Oliveira




             The user program calls an UI update function, either explicitly via UI update proxy API, or
             via proxy widget objects (in future versions).

             The UI update component updates the local copy of widgets/attributes (if needed), requests
             translation of any file elements (e.g. icons and pictures) to the UI file server component,
             and sends all needed data to the XML UI update dispatcher, which only encodes to XML
             and sends message via LRDP transport.

             The UI initialization message flows through the same steps.

5.3          5.3 UI update received at client side
                                                      CONFIDENTIAL                             14 (18)
                                                      DRAFT
INdT
Elvis Pfützenreuter                                   24.02.2006
Rosfran Borges
Flávio Oliveira




             The UI update message is decoded by the XML UI update receiver component, URLs are
             resolved into local files again those files are retrieved from server if they are not in local
             cache) and the interpreted data is sent above to the UI update driver.

             The UI update driver translates the event handlers into local proxy/stub event handlers,
             keeping a table of translations so the UI event component can discover the original event
             name in order to send it to the server; and drives the widget tree and/or widgets themselves
             in order to reflect the requested UI update in the renderer screen.

             UI update also translates Glade elements into Hildon elements when necessary, if the
             renderer is running under Maemo platform.

             The UI initialization message flows through the same steps. It is only simpler for the UI
             update driver to deal with, since it can be loaded at once by Glade instead of dealing with
             individual pre-existent widgets.


5.4          5.4 UI event initiated in client side
                                                     CONFIDENTIAL                            15 (18)
                                                     DRAFT
INdT
Elvis Pfützenreuter                                  24.02.2006
Rosfran Borges
Flávio Oliveira




             As explained in section 5.3, widget event handlers are all pointed to local proxy/stub
             handlers by the “UI Update Driver” client component.

             When something happens (got focus, lost focus, entry changed, button pressed), the proxy
             handler is called by the widget. In this particular sequence of events, Glade is not
             mentioned because events come directly from GTK+ widgets.

             The original event name is recovered from the table, and all data is sent to XML UI event
             encoding.


5.5          5.5 UI event received at server side




             Once the UI event arrives at server, it is decoded and the user-provided event handler is
             searched, based on received event name.

             The user application receives the event as it were running as a local GUI program.
                                                     CONFIDENTIAL                             16 (18)
                                                     DRAFT
INdT
Elvis Pfützenreuter                                  24.02.2006
Rosfran Borges
Flávio Oliveira


6.            UPNP VIEW

6.1           UPnP Server-side UI

             The server-side of the Remote UI is divided between UPnP Remote UI Server and the
             UPnP Remote UI Client. Both are usually remotely located entities, and an UPnP control
             point will interact with them in a way that they can deal with some of defined actions in the
             UPnP Remote UI.

             The UPnP RUI Server supports a single UPnP device service that allows control points to
             browse listings of compatible UIs (or protocols) that are remote-capable. The listings are
             composed of user-friendly meta data, URIs identifying the remote-able application user
             interfaces, and optional application and protocol-specific technical information for each UI.

             In addition, the UPnP RUI Client is another device, serving listings of application UIs. The
             URIs identifying the application may be associated with other devices within the network.
             The RUI Client entity is responsible for the most of the user session management
             messages, such as the ones related with the user-guided interfaces connections, like
             connecting and disconnecting from UIs instances, and information status about all the
             existent UI connections.

6.2           UPnP Client-side UI

             The client side of this architecture is represented by one component: the UPnP RUI Control
             Point. It is interacting with 2 services, one in the RUI Server device
             (RemoteUIServerService), and another in the RUI Client device (RemoteUIClientService).
             These services allows that control points can set up and manage connected UI sessions on
             a given RUI client/server.

             For this to work perfectly, client and server should agree perfectly on UI grammar (Glade)
             and UI widget libraries' versions. This agreement will have happened in session negotiation
             phase, done by UPnP.

6.3           Interaction with the UPnP Session management mechanism

             The RUI Server/RUI Client devices will be implemented using Cyberlink C Library, and the
             diagram below shows some of the dependency among all components. Note that the
             Control Point has a dependency both on the RUI Client and Server:
                                                    CONFIDENTIAL                           17 (18)
                                                    DRAFT
INdT
Elvis Pfützenreuter                                 24.02.2006
Rosfran Borges
Flávio Oliveira




             T
             h
             i
             s

             i
             s

             v
             e
             r
             y

             s
             i
             m
             i
             l
             a
             r
               to the Remote UI Client device of the class “Fully Remoted” (a kind of UPnP Remote UI
             configuration, described in the section 3.4.2, of the UPnP Remote UI Client Service
             document, see reference [1]), in a way that the RUI Client device hasn't the capability to
             receive and manage user interface listings (it hasn't implements the actions GetUIListing,
             AddUIListing and RemoveUIListing). So, the RUI Client is more dependent from the Control
             Point view, instead of to be loosely coupled the relation between CP and RUI Client. We
             can see playing this role a device like a TV set, a PVR set-top box, or a DVD player. The
             scenario representation below try to show a basic UPnP RUI interaction (actions on
             update/event UI content were not defined on the UPnP Remote UI restricted scenario we
             choose to use, based on the Widex Framework [8] ):




7.
REFERE
NCES

             [
             1
             ]

             U
             P
             n
             P
              Remote UI v1.0 Device Control Protocols, www.upnp.org

             [2]          NC44394 - “Nokia Desktop Protocol”
                                                CONFIDENTIAL                         18 (18)
                                                DRAFT
INdT
Elvis Pfützenreuter                             24.02.2006
Rosfran Borges
Flávio Oliveira


             [3]      “XUIKON – XML UI Framework”, Jussi Yli-Urpo, TP/Series 60/ATA

             [4]      Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080

             [5]      Glade – a User Interface Builder for GTK+ and Gnome,
                      http://glade.gnome.org/

             [6]      Stirbu; Raggett. Widget Description Exchange Service (WIDEX)
                      Requirements (draft-ietf-widex-requirements-00). IETF draft.

             [7]      Stirbu. LRDP: The Lightweight Remote Display Protocol.
                      draft-stirbu-lrdp-00.txt. IETF draft.

             [8]      Stirbu; Raggett. Widget Description Exchange Service (WIDEX)
                      Framework. draft-stirbu-widex-framework-00. IETF draft.

             [9]      Urpalainen. An Extensible Markup Language (XML) Patch Operations
                      draft-urpalainen-simple-xml-patch-ops-01. IETF draft.

             [10]     Vortex BEEP protocol library. http://www.aspl.es/vortex/


             [11]     PyMaemo project. http://pymaemo.sf.net

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:8/24/2011
language:English
pages:18