faculté des sciences appliquées département d’ingénierie informatique presented by transparent...
TRANSCRIPT
Faculté des sciences appliquées Département d’ingénierie informatique
Presented by
Transparent migration and Transparent migration and adaptation in a Graphical User adaptation in a Graphical User
Interface toolkitInterface toolkit
Donatien GrolauxDonatien GrolauxThesis Public DefenseThesis Public Defense
September 4September 4hh, 2007, 2007
ContextContext
Ubiquitous computingUbiquitous computing
UIs could take advantage of the ubiquity of devicesUIs could take advantage of the ubiquity of devices– MigrationMigration– AdaptationAdaptation
User centric view where the application follows the user User centric view where the application follows the user in its mobilityin its mobility
Unit Sales (per thousand)
0
100.000
200.000
300.000
400.000
500.000
600.000
700.000
800.000
900.000
1.000.000
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
Mobile Terminals
PC units
DemoDemo
PurposePurpose
Main goal: find a way to provide migration and Main goal: find a way to provide migration and adaptation support to applicationsadaptation support to applications– Introduce as little extra complexity as possibleIntroduce as little extra complexity as possible
How could that be achieved ?How could that be achieved ?– Ad hoc solution for each applicationAd hoc solution for each application– Do not touch the application, the migration/adaptation is Do not touch the application, the migration/adaptation is
provided externallyprovided externally
– Introduce extra models for the migration/adaptation and Introduce extra models for the migration/adaptation and have them executed at runtimehave them executed at runtime
– Provide the support for migration/adaptation in the toolbox Provide the support for migration/adaptation in the toolbox that builds the UI to provide migration/adaptationthat builds the UI to provide migration/adaptation
• Create a new toolbox from scratch ?Create a new toolbox from scratch ?
• Extend an existing toolboxExtend an existing toolbox
NoNo
NoNo
YesYes
NoNo
NoNo
YesYes
Approach of this thesisApproach of this thesis
Give a tool to the developers that enables them to create Give a tool to the developers that enables them to create multiplatform migratable & adaptable UIs.multiplatform migratable & adaptable UIs.– While minimizing the impact on the interactive applications While minimizing the impact on the interactive applications
implementationimplementation This tool is a graphical toolkitThis tool is a graphical toolkit
– That presents itself as a usual graphical toolkit (AWT, GTk, That presents itself as a usual graphical toolkit (AWT, GTk, Tcl/Tk…)Tcl/Tk…)
• Concepts of widgets, user events…Concepts of widgets, user events…– Multiplatform supportMultiplatform support– Migration supportMigration support– Adaptation supportAdaptation support– Some more featuresSome more features
Approach of this thesisApproach of this thesis
Do not try to solve discovery problems, context Do not try to solve discovery problems, context awareness, meta-UI, tasks specification…awareness, meta-UI, tasks specification…– It is up to the application to solve these issuesIt is up to the application to solve these issues
– However the tool allows for simple solutionsHowever the tool allows for simple solutions
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
OverviewOverview
Goal: create applications supporting Goal: create applications supporting migratable and adaptable user interfaces.migratable and adaptable user interfaces.
Means: a graphical toolkit supporting these Means: a graphical toolkit supporting these features, in an easy to use way.features, in an easy to use way.– Using a toolkit-agnostic middleware designed to Using a toolkit-agnostic middleware designed to
provide these extensionsprovide these extensions– By extending an existing toolkitBy extending an existing toolkit
Tools: the Oz programming language.Tools: the Oz programming language.– Support for distributed applicationsSupport for distributed applications– Multi-paradigm programming language (O-O, Multi-paradigm programming language (O-O,
symbolic programming, functional programming…)symbolic programming, functional programming…)
ApplicationApplication
This thesis allows writing applications whose This thesis allows writing applications whose UI:UI:– Is dynamically migratableIs dynamically migratable
– Is dynamically adaptableIs dynamically adaptableMozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
ApplicationApplication
Low development costLow development cost– Extend classical graphical toolkit approachExtend classical graphical toolkit approach
Give control to the application itselfGive control to the application itself DynamicityDynamicity Fault toleranceFault tolerance ExtensibleExtensible
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
MozartMozart
Multi-paradigm programming languageMulti-paradigm programming language– Strongly dynamically typedStrongly dynamically typed
– Procedural, Object-OrientationProcedural, Object-Orientation
– Functional, Logic and Symbolic programmingFunctional, Logic and Symbolic programming
– Transparent distribution supportTransparent distribution support• Distributed network protocols are attached automatically to Distributed network protocols are attached automatically to
some of the native data types of Ozsome of the native data types of Oz
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
EBL/TkEBL/Tk
Toolkit developped for this thesisToolkit developped for this thesis– Complete graphical UI toolkit with widgets, fonts, windows, dialog Complete graphical UI toolkit with widgets, fonts, windows, dialog
boxes…boxes…– Use a mixed declarative/imperative approachUse a mixed declarative/imperative approach
• Declarative approach for creating UIsDeclarative approach for creating UIs• Imperative approach for running UIsImperative approach for running UIs
UI={BuildUI={Build window(window( name:windowname:window selector(selector( name:selectorname:selector items:["Radiobuttons" "Listbox" "Menu"]items:["Radiobuttons" "Listbox" "Menu"] curselection:1curselection:1 text:"Selector"text:"Selector" action:action:proc{$}proc{$} R={UI.selector get(curselection:$)}R={UI.selector get(curselection:$)} inin {UI.selector setContext((default#listbox#menu).R)}{UI.selector setContext((default#listbox#menu).R)} endend))))}}{UI.window show}{UI.window show}
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
EBL/Tk AdaptationEBL/Tk Adaptation
Adaptation is a special configuration parameterAdaptation is a special configuration parameter
UI={Build UI={Build window(window( name:windowname:window selector(selector( name:selectorname:selector items:["Radiobuttons" "Listbox" "Menu"]items:["Radiobuttons" "Listbox" "Menu"] curselection:1curselection:1 text:"Selector"text:"Selector" action:proc{$}action:proc{$} R={UI.selector get(curselection:$)}R={UI.selector get(curselection:$)} inin {UI.selector setContext((default#listbox#menu).R)}{UI.selector setContext((default#listbox#menu).R)} end))}end))}{UI.window show}{UI.window show}
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
EBL/Tk MigrationEBL/Tk Migration
Capability based migrationCapability based migration– Capability represents the authority to migrate a widgetCapability represents the authority to migrate a widget
– Capability contains the Internet address of the widgetCapability contains the Internet address of the widget
– All widgets All widgets (except toplevel widgets)(except toplevel widgets) have the migration have the migration capabilitycapability
{Offer {Offer {UI.selector getRef($)}{UI.selector getRef($)}}}
UI2={Build window(name:window)}UI2={Build window(name:window)}
{UI2.window show}{UI2.window show}
{UI2.window display({Obtain})}{UI2.window display({Obtain})}MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Transparent Migration and AdaptationTransparent Migration and Adaptation
Transparent migrationTransparent migration– Widgets are used by the application indifferently of their Widgets are used by the application indifferently of their
actual situation (local/remote) as if they were always local.actual situation (local/remote) as if they were always local.– The migration can happen at any time, and the protocol is The migration can happen at any time, and the protocol is
executed independently of the concurrent running executed independently of the concurrent running application.application.
Transparent adaptationTransparent adaptation– Widgets are used by the application indifferently of their Widgets are used by the application indifferently of their
actual visual representation as if there was only one actual visual representation as if there was only one representation.representation.
– The adaptation can happen at any time, and the protocol The adaptation can happen at any time, and the protocol is executed independently of the concurrent running is executed independently of the concurrent running application.application.
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Thesis main contribution: EBLThesis main contribution: EBL
Middleware that has to be interfaced to an existing Middleware that has to be interfaced to an existing toolkittoolkit– Toolkit agnostic, could be interfaced to any Toolkit agnostic, could be interfaced to any
Infrastructure for migration Infrastructure for migration Distributed environmentDistributed environment
Device 1
Device 2
Device 3MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Distributed ToolkitDistributed Toolkit
Application is stationary, widget is migratoryApplication is stationary, widget is migratory– Two parts: proxy & rendererTwo parts: proxy & renderer
Site A
Site B
Site C
Proxy A1
Proxy A2
Proxy C1Renderer A1
Renderer A2
Renderer C1
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Fault ToleranceFault Tolerance
Network fault toleranceNetwork fault tolerance– Proxy has the complete stateProxy has the complete state
– Renderer eventually notified of state update, reflected to Renderer eventually notified of state update, reflected to the widgetthe widget
Site A
Site B
Site C
Proxy A1
Proxy A2
Proxy C1Renderer A1
Renderer A2
Renderer C1
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Site D
Renderer C2
MigrationMigration
Dynamic creation of a rendererDynamic creation of a renderer– Linked to a proxyLinked to a proxy
– Using local resourcesUsing local resources
Site A
Proxy A1
Site B
Renderer A1
Local Resources
Local Resources
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Geometry ManagementGeometry Management
Geometry is managed by hierarchy of container widgetsGeometry is managed by hierarchy of container widgets– Root widget: toplevelRoot widget: toplevel
• Toplevel is rooted at the application that creates itToplevel is rooted at the application that creates it
– tdtd and and lrlr widgets provide compact syntax for tables widgets provide compact syntax for tables
Site A
Display AApplication A
Toplevel Proxy Toplevel Renderer
Site B
Application B
Widget Proxy
Widget Renderer
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Migration MechanismMigration Mechanism
Migration based on capabilityMigration based on capability– Embeds the authority to migrate the widget (PULL)Embeds the authority to migrate the widget (PULL)
– Embeds the Internet address of the widgetEmbeds the Internet address of the widget Migration triggered by giving the migration capability to a Migration triggered by giving the migration capability to a
container widgetcontainer widget
Application A
Widget ProxyRef
Discovery Service
Ref
Application B
Window Proxy
get Ref
Ref
Window Renderer
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Widget Renderer
AdaptationAdaptation
Alternate compatible renderersAlternate compatible renderers
Widget X definition
Widget Y definition
Proxy Y
Renderer Y1
Renderer Y2
Renderer Y3
Proxy X Renderer X1
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
AdaptationAdaptation
Adaptation is supported by dynamically switching the rendererAdaptation is supported by dynamically switching the renderer
Switching the renderer is implemented by migrating the widget Switching the renderer is implemented by migrating the widget into the place it already occupies, but using a different renderer into the place it already occupies, but using a different renderer definitiondefinition
Application A
Proxy Y
Application B
Renderer Y1
Application A
Proxy Y
Application B
Renderer Y2
Adaptation of Y, from renderer Y1 to Y2
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Proxy-RendererProxy-Renderer
Collaboration implemented by shared memory Collaboration implemented by shared memory abstraction: storeabstraction: store– StoreName X KeyName -> KeyValueStoreName X KeyName -> KeyValue
– Type checking, transparent marshallingType checking, transparent marshalling
Application A Application B
Widget Proxy
- public APIEBL Manager
EBL Store x
EBL Store y
EBL Store z
Widget Renderer
- EBL compatible APIEBL Manager
EBL Store x
EBL Store y
EBL Store z
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
DelegationDelegation
In an ideal situation, the functional core of the widget is In an ideal situation, the functional core of the widget is reproduced at its proxyreproduced at its proxy– Require development costRequire development cost– Functional core typically already present at the rendererFunctional core typically already present at the renderer
A delegation mechanism allows the proxy to rely on a A delegation mechanism allows the proxy to rely on a renderer for a state updaterenderer for a state update– The proxy sends the request to the renderer and waits for The proxy sends the request to the renderer and waits for
its responseits response– The renderer uses the toolkit to apply the requestThe renderer uses the toolkit to apply the request– The renderer gets back the resulting state, and responds to The renderer gets back the resulting state, and responds to
the proxythe proxy– The proxy updates its state accordinglyThe proxy updates its state accordingly
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Delegation ExampleDelegation Example
ProxyProxy
meth change(Something)meth change(Something)
OldState={Store get(main state $)}OldState={Store get(main state $)}
NewState={NewState={DiffDiff OldState Something} OldState Something}
inin
{Store set(main state NewState)}{Store set(main state NewState)}
endend
meth change(Something)meth change(Something)
NewState={Manager ask(Something $)}NewState={Manager ask(Something $)}
InIn
{Store set(main state NewState)}{Store set(main state NewState)}
endend
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
RendererRenderer
meth set(I K V)meth set(I K V)
case I#K of main#state thencase I#K of main#state then
{Toolkit apply(state V)}{Toolkit apply(state V)}
endend
endend
meth ask(Q R)meth ask(Q R)
{Toolkit apply(state Q)}{Toolkit apply(state Q)}
R={Toolkit getState($)}R={Toolkit getState($)}
endend
No
De
leg
ati
on
De
leg
ati
on
StateT1T2Proxy
State | T1, T2, …
Proxy
State’ | T2, …
Transaction protocol for DelegationTransaction protocol for Delegation
Delegation is implemented by transactionsDelegation is implemented by transactions– Transactions are resolved in the order they are submitted.Transactions are resolved in the order they are submitted.
– At the proxy, transaction requests blocks until they are At the proxy, transaction requests blocks until they are committed.committed.
– For a transaction to commit, the renderer must survive long For a transaction to commit, the renderer must survive long enough to give its answer.enough to give its answer.
– When that is not the case, the transactions keeps on When that is not the case, the transactions keeps on blocking until a new renderer comes in.blocking until a new renderer comes in.
• The state of the renderer is first synchronized to the current The state of the renderer is first synchronized to the current state of the proxy.state of the proxy.
• Transactions are then retried, still respecting the order in which Transactions are then retried, still respecting the order in which they are submittedthey are submitted
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Renderer
StateResp T1Resp T2
ReflexivityReflexivity
Build function is also available at the rendererBuild function is also available at the renderer– Allows the creation of compound widgets using the high Allows the creation of compound widgets using the high
expressivity level of EBL even when implementing the low expressivity level of EBL even when implementing the low level renderer.level renderer.
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Frame={New Toolkit.frame tkInit(parent:Parent)}Frame={New Toolkit.frame tkInit(parent:Parent)}
YesButton={New Toolkit.button tkInit(parent:Frame)}YesButton={New Toolkit.button tkInit(parent:Frame)}
{YesButton tk(configure(text:“Yes”))}{YesButton tk(configure(text:“Yes”))}
NoButton={New Toolkit.button tkInit(parent:Frame)}NoButton={New Toolkit.button tkInit(parent:Frame)}
{NoButton tk(configure(text:”No”))}{NoButton tk(configure(text:”No”))}
{Toolkit.pack YesButton}{Toolkit.pack YesButton}
{Toolkit.pack NoButton}{Toolkit.pack NoButton}
Widgets={Manager build(lr(name:frame Widgets={Manager build(lr(name:frame
button(text:”Yes”) button(text:”No”)) $)}button(text:”Yes”) button(text:”No”)) $)}
Frame=Widgets.frameFrame=Widgets.frame
Model based approach using EBLModel based approach using EBL
Let’s consider an application specific modelLet’s consider an application specific model– Implemented by Oz data structuresImplemented by Oz data structures
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
data(name:"Roger"data(name:"Roger" surname:"Rabbit"surname:"Rabbit" address1:"Rue des toons"address1:"Rue des toons" address2:"WB")address2:"WB")
fun{Transform2 D}fun{Transform2 D} fun{Loop P}fun{Loop P} case P of I#E|Xs thencase P of I#E|Xs then label(text:I)|label(text:I)| label(text:E)|label(text:E)| newline|newline| {Loop Xs}{Loop Xs} else nil endelse nil end endendinin {List.toTuple lr{List.toTuple lr {Loop {Record.toListInd D}}}{Loop {Record.toListInd D}}}endend
Model based approach using EBLModel based approach using EBL
Let’s consider an application specific modelLet’s consider an application specific model– Implemented by Oz data structuresImplemented by Oz data structures
– Functional paradigm of Oz manipulates these data Functional paradigm of Oz manipulates these data structuresstructures
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
data(name:"Roger"data(name:"Roger" surname:"Rabbit"surname:"Rabbit" address1:"Rue des toons"address1:"Rue des toons" address2:"WB")address2:"WB")
fun{Transform1 D}fun{Transform1 D} {List.toTuple td{List.toTuple td {List.map{List.map {Record.toListInd D}{Record.toListInd D} fun{$ I#E}fun{$ I#E} lr(label(text:I)lr(label(text:I) label(text:E))label(text:E)) end}}end}}endend
td(lr(label(text:address1)td(lr(label(text:address1) label(text:"Rue des toons"))label(text:"Rue des toons")) lr(label(text:address2)lr(label(text:address2) label(text:"WB"))label(text:"WB")) lr(label(text:name)lr(label(text:name) label(text:"Roger"))label(text:"Roger")) lr(label(text:surname)lr(label(text:surname) label(text:"Rabbit")))label(text:"Rabbit")))
+
lr(label(text:address1) lr(label(text:address1) label(text:"Rue des toons") newlinelabel(text:"Rue des toons") newline label(text:address2)label(text:address2) label(text:"WB") newlinelabel(text:"WB") newline label(text:name)label(text:name) label(text:"Roger") newlinelabel(text:"Roger") newline label(text:surname)label(text:surname) label(text:"Rabbit") newline)label(text:"Rabbit") newline)
Model based approach using EBLModel based approach using EBL
Let’s consider an application specific modelLet’s consider an application specific model– Implemented by Oz data structuresImplemented by Oz data structures
– Functional paradigm of Oz manipulates these data Functional paradigm of Oz manipulates these data structuresstructures
– End result is a valid EBL/Tk description recordEnd result is a valid EBL/Tk description record
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
lr(label(text:address1) lr(label(text:address1) label(text:"Rue des toons") newlinelabel(text:"Rue des toons") newline label(text:address2)label(text:address2) label(text:"WB") newlinelabel(text:"WB") newline label(text:name)label(text:name) label(text:"Roger") newlinelabel(text:"Roger") newline label(text:surname)label(text:surname) label(text:"Rabbit") newline)label(text:"Rabbit") newline)
td(lr(label(text:address1)td(lr(label(text:address1) label(text:"Rue des toons"))label(text:"Rue des toons")) lr(label(text:address2)lr(label(text:address2) label(text:"WB"))label(text:"WB")) lr(label(text:name)lr(label(text:name) label(text:"Roger"))label(text:"Roger")) lr(label(text:surname)lr(label(text:surname) label(text:"Rabbit")))label(text:"Rabbit")))
lr(label(text:address1) lr(label(text:address1) entry(text:"Rue des toons") newlineentry(text:"Rue des toons") newline label(text:address2)label(text:address2) entry(text:"WB") newlineentry(text:"WB") newline label(text:name)label(text:name) entry(text:"Roger") newlineentry(text:"Roger") newline label(text:surname)label(text:surname) entry(text:"Rabbit") newline)entry(text:"Rabbit") newline)
Model based approach using EBLModel based approach using EBL
Let’s consider an application specific modelLet’s consider an application specific model– Implemented by Oz data structuresImplemented by Oz data structures
– Functional paradigm of Oz manipulates these data Functional paradigm of Oz manipulates these data structuresstructures
– End result is a valid EBL/Tk description recordEnd result is a valid EBL/Tk description record
– Alternate renderings are placed into alternate renderersAlternate renderings are placed into alternate renderers• Because of the reflexivity, this is a straightforward processBecause of the reflexivity, this is a straightforward process
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/TkData=data(name:"Roger"Data=data(name:"Roger" surname:"Rabbit"surname:"Rabbit" address1:"Rue des toons"address1:"Rue des toons" address2:"WB")address2:"WB")
All={Build window(form(data:Data name:form) name:top)}All={Build window(form(data:Data name:form) name:top)}
{All.top show}{All.top show}{All.form setContext(unalignedview)}{All.form setContext(unalignedview)}{All.form setContext(alignedview)}{All.form setContext(alignedview)}{All.form setContext(alignededit)}{All.form setContext(alignededit)}
EvaluationEvaluation
Performance overheadPerformance overhead– When no delegation is used, EBL runs in an asynchronous When no delegation is used, EBL runs in an asynchronous
wayway• 328 ms for 20 000 operations328 ms for 20 000 operations
– When delegation is used, EBL runs in a synchronous wayWhen delegation is used, EBL runs in a synchronous way• 1780 ms for 20 000 operations1780 ms for 20 000 operations
– Network overheadNetwork overhead• Typically way greater than EBL overheadTypically way greater than EBL overhead• Typically the throughput limitation can be felt only when Typically the throughput limitation can be felt only when
sending huge amount of data in a small window of time, which sending huge amount of data in a small window of time, which does not happen often with EBLdoes not happen often with EBL
• For asynchronous operations: the application is not slowed For asynchronous operations: the application is not slowed down, the UI lags behind by the network delay timedown, the UI lags behind by the network delay time
• For synchronous operations: the application is slowed down For synchronous operations: the application is slowed down 2Xnetwork delay2Xnetwork delay
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
EvaluationEvaluation
ExpressivenessExpressiveness– Full fledged graphical toolkit.Full fledged graphical toolkit.– The declarative approach greatly reduces the size of the code The declarative approach greatly reduces the size of the code
required for building a UI (QTk experiment: down to 1/3 the required for building a UI (QTk experiment: down to 1/3 the size).size).
– The mixing of declarative and imperative approaches allows The mixing of declarative and imperative approaches allows the creation of adaptative UIs at reduced cost (FlexClock the creation of adaptative UIs at reduced cost (FlexClock experiment: 300 lines of code for 17 different views). experiment: 300 lines of code for 17 different views).
– The transparent migration approach allows migrating whole The transparent migration approach allows migrating whole UIs with few lines of code.UIs with few lines of code.
– The transparent adaptation approach allows adaptating whole The transparent adaptation approach allows adaptating whole UIs with few lines of code.UIs with few lines of code.
– The delegation greatly lowers the actual toolkit binding The delegation greatly lowers the actual toolkit binding development cost.development cost.
– The extensibility of EBL allows reusability.The extensibility of EBL allows reusability.
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
ConclusionConclusion
We have a GUI toolkitWe have a GUI toolkit– That runs, is available and is documentedThat runs, is available and is documented– Which is expressively equivalent to usual GUI toolkitsWhich is expressively equivalent to usual GUI toolkits– Which is often more expressive and simpler than usual GUI Which is often more expressive and simpler than usual GUI
toolkits (imperative/declarative approach)toolkits (imperative/declarative approach)– Runs on all platforms supported by Mozart (Mac OS X, Runs on all platforms supported by Mozart (Mac OS X,
Windows, Linux, Unix…)Windows, Linux, Unix…)– Supports dynamic migrationSupports dynamic migration– Supports dynamic adaptationSupports dynamic adaptation– Is easily extensibleIs easily extensible
Shortcomings and Future workShortcomings and Future work
Tcl/Tk is agingTcl/Tk is aging– Replace it by a more up to date toolkit (GTk)Replace it by a more up to date toolkit (GTk)
Limitations of the current implementationLimitations of the current implementation– Concurrent multi-toolkit supportConcurrent multi-toolkit support– Limited multi-user functionalityLimited multi-user functionality
Communications between proxy and renderer is Communications between proxy and renderer is restricted (store, delegation)restricted (store, delegation)– Expressivity is enough for EBL/Tk, but is it general enough?Expressivity is enough for EBL/Tk, but is it general enough?
Address security issuesAddress security issues Explore multiExplore multi-user aspects-user aspects Explore usability aspectsExplore usability aspects
The EndThe End
More slides just in caseMore slides just in case
MultiMulti-paradigm & adaptation-paradigm & adaptation
Functional, Logic and Symbolic programmingFunctional, Logic and Symbolic programming
data(name:"Roger"data(name:"Roger"
surname:"Rabbit"surname:"Rabbit"
address1:"Rue des toons"address1:"Rue des toons"
address2:"WB")address2:"WB")
td(lr(label(text:address1)td(lr(label(text:address1)
label(text:"Rue des toons"))label(text:"Rue des toons"))
lr(label(text:address2)lr(label(text:address2)
label(text:"WB"))label(text:"WB"))
lr(label(text:name)lr(label(text:name)
label(text:"Roger"))label(text:"Roger"))
lr(label(text:surname)lr(label(text:surname)
label(text:"Rabbit")))label(text:"Rabbit")))
lr(label(text:address1)lr(label(text:address1)
label(text:"Rue des toons") newlinelabel(text:"Rue des toons") newline
label(text:address2)label(text:address2)
label(text:"WB") newlinelabel(text:"WB") newline
label(text:name)label(text:name)
label(text:"Roger") newlinelabel(text:"Roger") newline
label(text:surname)label(text:surname)
label(text:"Rabbit") newline)label(text:"Rabbit") newline)
F1 F2
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
Adaptation ProtocolAdaptation Protocol
RMPM RC
setContext(N)replace
replace
destroy
getClassDef
connectManager
current state
RC2
apply current state
classDef
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk
state update
Migration ProtocolMigration Protocol
RCPC PM
getRefPM ref
importHere(Ref PI)
getClassDef
classDef
create envcreate manager
connectManager
current state
create RM
RM
state update
apply current state
MozartMozart
TCP/IPTCP/IP
DistributionDistribution
LayerLayer
ApplicationApplication
EBL/TkEBL/Tk
EBLEBL
Tcl/TkTcl/Tk