Faculté des sciences appliquées Département d’ingénierie informatique Presented by Transparent...

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…)


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


LayerLayer


EBL/TkEBL/Tk

EBLEBL

Tcl/TkTcl/Tk


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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



– Functional paradigm of Oz manipulates these data Functional paradigm of Oz manipulates these data structuresstructures

MozartMozart

TCP/IPTCP/IP


LayerLayer


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)




– End result is a valid EBL/Tk description recordEnd result is a valid EBL/Tk description record

MozartMozart

TCP/IPTCP/IP


LayerLayer


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)




– 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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


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


LayerLayer


EBL/TkEBL/Tk

EBLEBL

Tcl/TkTcl/Tk

Faculté des sciences appliquées Département d’ingénierie informatique Presented by Transparent...

Documents

Transcript of Faculté des sciences appliquées Département d’ingénierie informatique Presented by Transparent...