the present invention will now be described more fully hereinafter with reference to the accompanying drawings , in which currently preferred embodiments of the invention are shown . this invention may , however , be embodied in many different forms and should not be construed as limited to the embodiments set forth herein ; rather , these embodiments are provided for thoroughness and completeness , and fully convey the scope of the invention to those skilled in the art . like reference characters refer to like elements throughout . referring now to the drawings and fig1 in particular , there is depicted the main components in an embodiment of the invention . in fig1 is depicted a client - server network 100 where a client device 102 is connected to a server 104 over a computer network 106 . although there is only a single client device 102 depicted in fig1 , the client - server network may typically comprise a plurality of clients connected to the server . the computer network 106 may be a wired computer network such as a wan ( wide area network ) or a lan ( local area network ) to enable fast and reliable communication between the client device 102 and the server 104 . however , a wireless communication link may also be utilized . the client device 102 is here a thin client device provided with a touch screen . however , other devices may also serve as a client device such as , for example , a digital tv , a computer screen or a mobile phone . furthermore , other input means such as e . g . a keyboard , mouse , joystick , or a remote control may be utilized in addition to or instead of the touch screen . an application platform , here being an xml ( extensible mark - up language ) based service delivery platform 108 , is installed on the server 104 to model the client - server network 100 . although the illustrated client - server network 100 has a single server 104 , the service delivery platform 108 may provide remote hosting with any number of distributed servers that may be child servers , parent servers , or clustered servers . a plurality of service applications 110 are plugged into the service delivery platform 108 , wherein each service application is a computer program configured to provide meta - information to the service delivery platform 108 . accordingly , the service application provides an abstract description of a service ( including application logic , i . e . logic to handle specific events ) that is to be performed by the client device without any details that requires knowledge about client - specific information such as the client hardware , protocols used , etc . examples of possible services are news highlights ; traffic camera ; e - mail ; weather forecast ; calendar ; house entry phone service ; and laundry booking service . the service applications 110 may , for example , be implemented as . net based dynamic - link libraries ( dlls ) 112 . fig2 schematically illustrates how a gui 200 can be generated on the client device from four types of input data using a renderer . the four types of input data are : a client display resolution 201 ; a macro - layout 202 ; a set of micro - layouts 203 ; and a theme 204 . the interface 200 is here a so - called “ ten foot interface ”. the ten foot interface typically has a less detailed and less complex layout than a “ two foot interface ” used by a conventional computer monitor . thus , the ten foot interface can preferably be used for screens having a lower resolution than a conventional computer monitor , such as e . g . a tv - screen or a user interface for a control system . although the name suggests that the ten foot interface is designed and proportioned to be viewed at a distance of about ten feet , rather than a viewing distance of about two foot as is the case for a conventional computer monitor , the ten foot interface may be convenient also for shorter viewing distances . for example , a ten foot interface can preferably be used for a gui displayed on a small screen , such as on a mobile phone , or on a touch screen . the client display resolution 201 can be provided by an initialization function containing a script that evaluates the available resolution of the display of the client device . as an alternative , the resolution 201 can be provided by an url ( uniform resource locator ), for example , when a http based protocol is used . the macro - layout 202 is meta - information that determines the division of the available client display resolution into sub regions 202 a - c . ( to avoid cluttering the figure only three of the sub regions have been provided with a reference numeral .) the macro - layout contains no absolute positions , thus making it scalable . further , for each sub region , the macro - layout 202 determines which service should be displayed therein by pointing to one of the service applications 110 , and determining whether the service application will be displayed as a brieflet , button , dialog , header , dynamic menus , etc . the macro - layout is typically provided by the service delivery platform 108 , and may , for example , be set by a user in a setup menu on the client device . the micro - layouts 203 a - c are meta - information that provide the content and layout of the service assigned to each sub region 202 a - c . to avoid cluttering the figure only three of micro - layouts have been provided with a reference numeral . for example , the illustrated micro - layouts 203 a - c may provide news highlights , traffic camera , and e - mail . the micro - layout contains no absolute positions , thus making it scalable . micro - layouts are part of the code of the service applications , 110 . furthermore , by calling additional service applications from the micro - layout of a “ parent ” service application , a service package can be created that displays the information or functions from several service applications . the theme 204 is a set of graphic attributes to provide a desired “ look and feel ” of the gui . the theme typically determines the visual appearance in terms of colors , background images , font styles , font sizes , spacing , paragraph style formatting , etc . themes enable the gui to be displayed in a variety of styles , and can be used for company branding or to give end - users a menu of styles to suit personal preferences . the themes can be created in e . g . visual studio , adobe illustrator , and photoshop , and can be implemented by a theme definition file and a style guide file which files typically are different for different renderers . style guide files used for html / http are written in cssx , i . e . css ( cascading style sheets ) files with embedded script to make them dynamic , whereas style guide files used for bmp ( bitmap ) and / or tcp are specified using xml . the theme definition file establishes the theme as an object in the service delivery platform , whereas the style guide file provides the style parameters . the style guide file typically differs for different renderer base types , such as html / http , svg / http , bmp / tcp . for example , there are different style guide files for bmp clients , dhtml ( dynamic hypertext markup language ) clients ( e . g . laptop screens , browsers ), and svg clients ( e . g . mobile phones ). the client - server network 100 also includes a set of rendering plug - ins 112 to help transform the macro - layout 202 and the micro - layouts 203 into a gui 200 . each rendering plug - in is a computer program , plugged in to the service delivery platform 108 , and being configured to create a client specific application by transforming a macro - layout 202 and its associated micro - layouts 203 into a client specific application 114 by limiting the macro - layout to the client display resolution , limiting the micro - layouts to the sub regions , and applying an appropriate theme . the resulting client specific application 114 can then be executed by a specific client device 102 to render a gui 200 . it can be noted that the rendering plug - ins 112 only handles the hardware resources and capabilities of the client device , and thus require no knowledge about the functionality , of the services . this makes it easy to develop service applications for a variety of clients of different types , and virtually eliminates the need to modify the service applications when new types of clients are introduced . it is recognized that the client specific application will vary based on the type of rendering plug - in used . for example , a dhtml rendering plug - in renders content as dhtml for web browser access , whereas a bitmap rendering plug - in renders the entire screen at the server and sends it to the client device as a bitmap . as the bitmap - based gui is used , only the active portions of the screen are sent and the client device updates the corresponding regions accordingly . multiple layers are maintained to handle client animation during user interaction . another example of a rendering plug - in is an svg rendering plug - in , which may preferably be used for embedded devices such as set top boxes and mobile phones where smaller graphics files are a distinct advantage . the rendering plug - ins may be categorized into standard rendering plug - ins and client specific rendering plug - ins . unlike the client specific rendering plug - ins , the standard rendering plug - ins has not been configured to handle a specific client . the client specific rendering plug - ins may be based on the standard rendering plug - ins . thus , it is only required to implement support for what is really unique for that client device , such as , e . g . connection to media player , or specific hardware resources , etc . the operation of the client - server network 100 will now be described with reference to the schematic block diagram in fig3 . as the client device 102 is connected to the client - server network 100 , the client screen resolution is evaluated by the initialization function in step 301 , or , if the client connects using http , the resolution is provided in an url . further , in step 302 , the client device 102 sends an application request to the service delivery platform 108 . the application request includes a client specification which may be an xml - document comprising identification information that may be relevant when selecting an appropriate rendering plug - in 112 . alternatively , if http is used as a communication protocol , the identification information may be included in a http request header as a so - called user agent , i . e . a string that comprises e . g . browser family , hardware platform , and version . this is typically sufficient information to determine how well the client device 102 is supported by a rendering plug - in 110 . however , it is recognized by a person skilled in the art that the content of the identification information may vary . for example , a client device id may be used to identify the client device instead of the user agent . also , information about hardware resources of the client device may be included in the client specification ( such as resolution , video / audio codecs , tuners , leds ( light emitting diodes ), meters and controllable device , etc ) to help determine how well the client device is supported by a rendering plug - in . furthermore , in the bmp / tcp case , information that is sent in http request headers in the http case , are sent in a specific handshake message , that is part of the home arena bitmap protocol ( proprietary protocol ). in step 303 , a list of available rendering plug - ins is provided by the service delivery platform 108 . this typically includes all of the rendering plug - ins that are plugged in to the service delivery platform . in step 304 , a compatibility rating is determined by each available rendering plug - in 112 . this rating may be based on implicit information and / or on explicit information . for example , if http is used as a communication protocol , all the rendering plug - ins 112 that do not support http may be excluded . each of the remaining rendering plug - ins 112 may then determine a compatibility rating on how well it supports the specific client device in question based on the information in the user agent . it may be convenient to use a compatibility rating divided into , for example , five degrees , such as : “ not at all ”, “ barely ”, “ ok ”, “ well ”, and “ perfect ”. here “ not at all ” means that the client device is definitely not supported by the rendering plug - in in question , “ barely ” means that it is undecided but there is a chance that the client device is supported by the rendering plug - in , “ ok ” means that the most fundamental features are supported , “ well ” means that the rendering plug - in is adapted to handle the specific brand of the client device in question , whereas “ perfect ” means that the rendering plug - in is adapted to handle the specific brand and model of the client device in question . the resulting compatibility rating is then reported by each rendering plug - in 112 to the service delivery platform 108 . for example , as a motorola vip - 1910 set - top - box running an html browser ( based on the firefox browser ) connects to the server , the following renderers would return the following support grades : in step 305 , the service delivery platform 108 selects one rendering plug - in based on a predetermined criterion . the predetermined criterion may be that the compatibility rating should meet at least a predetermined compatibility level . for example , the service delivery platform may choose the first rendering plug - in found that has a compatibility rating being at least “ ok ”. however , more preferably the predetermined criterion may be to select the rendering plug - in having the highest relative compatibility rating among the available rendering plug - ins , or if there is more than one rendering plug - in that has obtained the highest relative rating , selecting one of these , e . g . the one that is first encountered . note that the service delivery platform 108 here selects the rendering plug - in 108 with the highest relative compatibility rating , even if the absolute level of the compatibility rating is low . this means that , unless all available rendering plug - ins has the rating “ not at all ”, the client device will always have some support by the service delivery platform 108 , even if there may be many features that will not be supported . if all rendering plug - ins has the rating “ not at all ” the client device is denied access . in step 306 , the selected rendering plug - in retrieves a file containing the currently selected macro - layout , and provides the layout 202 described therein . in doing so , the size of the macro - layout is limited to the available screen resolution determined in step 301 . in step 307 , the rendering plug - in 112 calls the service application 110 associated with each the sub region 202 a - c using the pointers in the macro - layout file . thus , for each sub region , the rendering plug - in displays the service according to the corresponding micro - layout 203 a - c in the service application . in doing so , the size of each micro - layout 203 a - c is limited to the size of its associated sub region . furthermore , as illustrated by step 308 , the currently selected theme for colors and style is applied . then , in step 309 , the resulting client specific application is sent to the client device 102 where it is executed to display a gui 200 on the touch screen of the client device . in addition to displaying information to a user , the gui typically includes interaction logic that may handle events etc . therefore , the rendering plug - in may preferably be configured also to convert an output from the client specific application executed on the client device to an input interpretable by the service applications . examples of micro - layout elements that may render client user interaction logic are : command area : if clicking inside a command area , a click event is sent to the service application that produced the element . a command area can come in different styles : transparent , normal ( i . e . has a highlighted background when clicked ), boxed ( area surrounded by a box ), etc . it can also have quick keys ( 1 , 2 , 3 . . .) which can be used by the client device , if supported . on set - top - boxes these quick keys can be rendered to logic that detects the use of the red , green , blue and yellow buttons , for example . buttons : content rendered within a graphic button that is visibly pressed when clicked . otherwise works as a command area , but is easier for client devices to use if only a button is desired . click area : an area , that when clicked , the coordinates within the area are sent back to the service application ( in relative coordinates , not screen coordinates — which are client specific ). menu item : works as a command area , but a different menu selection event is created . text input areas : text input using keyboards , remote controls , or virtual keyboards are handled using client interaction logic . two types of events are sent from the client specific application to the generic service application creating this element . the first type of events is asynchronous text update events . these are not sent for every key , but regularly ( depending on network performance , etc .) to keep the application aware of what the user is typing . the second type of events is an update event when the user is finished typing or goes to the next page , etc . channelchanged : channel input ( i . e . switching channels on a tv ) is handled much in the same way as text input above . client specific applications can themselves send asynchronous events to service applications to report different status information . for example , the client can report dvb tuner search status while searching ( and finding ) channels . possibly , a list of available hardware resources is reported by the client device 114 when the rendering plug - in has been assigned . this list may preferably comprise a specification over all hardware resources available to the client , categorized as well as with information about parameters , commands , etc . these hardware resources can then be published by the service delivery platform 108 , via the rendering plug - ins 112 , to available service applications 110 . the service applications 110 can then interact with the hardware resources via these parameters and commands , and the rendering plug - ins 112 provides that communication . also , the service delivery platform may support free communication from client to server , but also from server to client . although , communication can only be initiated by the client for certain protocols ( e . g . http ), the rendering plug - in solves this so that service applications on the server can send messages to the clients , although http is used . this can be done using an xmlhttprequest - object . two methods can be used : either repetitive polling , when the client repetitively ( using a configurable time interval ) asks the server if changes or messages are available ( which are stored in queues on the server ). the other method is to use delayed responses , i . e . the client asks the server “ whats new ?”, but the server waits ( up to a configurable period of time ) for something to happen before responding . if nothing has happened , an empty response is returned , and the client immediately asks again . using any of these techniques it is possible to push information from the server to the client , using the http protocol , regardless of the fact that http is client driven , i . e . communication can only be instantiated from the client . the person skilled in the art realizes that the present invention is not limited to the preferred embodiments . for example , the compatibility rating is not limited to the client display , but is also applicable for other hardware resources of the client , e . g . to determine if a specific sound or video file can be played on the client in question . furthermore , although the service applications have been described as . net - based dynamic - link libraries ( dlls ) the invention is not limited thereto . there may also be specific services that convert logic stored in xml - files to meta - information . this enables an application which is specified in a xml - file to be plugged in to the service delivery platform without a need to code it in . net . an example thereof would be an xml - service engine which may take an xml - file ( with optional embedded script via a script engine ), for example including a request form , convert it to a dynamic meta - information , handle the interaction of the user , etc . other examples may be podcasts , video definitions , web cameras , etc which can all be specified by simple xml - files , without a need to code them in . net . such and other obvious modifications must be considered to be within the scope of the present invention , as it is defined by the appended claims . it should be noted that the above - mentioned embodiments illustrate rather than limit the invention , and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims . in the claims , any reference signs placed between parentheses shall not be construed as limiting to the claim . the word “ comprising ” does not exclude the presence of other elements or steps than those listed in the claim . the word “ a ” or “ an ” preceding an element does not exclude the presence of a plurality of such elements . further , a single unit may perform the functions of several means recited in the claims . also , the disclosed method steps may be executed in any different order .