"I see eyes in my soup": How Delivery Hero implemented the safety system for ...
Engineering Concurrent and Event-driven Web Apps: an Agent-Oriented Approach based on the simpAL languagen
1. ENGINEERING CONCURRENT AND EVENT-DRIVEN
WEB APPS: AN AGENT-ORIENTED APPROACH
BASED ON THE SIMPAL LANGUAGE
ALMA MATER STUDIORUM
UNIVERSITÀ DI BOLOGNA
SECONDA FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA MAGISTRALE IN INGEGNERIA INFORMATICA
SUPERVISOR:
PROF. RICCI ALESSANDRO
CO-SUPERVISOR:
DOTT. SANTI ANDREA
PRESENTED BY:
DOTT. FABBRI FRANCESCO
2. Objectives
Objectives:
Analysis of state-of-the-art technologies for Web apps
programming
Focusing on:
→ Asynchronous programming
→ Concurrency
→ Related problems
Investigating how the Agent-oriented programming
paradigm could enhance Web apps programming
→ simpAL as reference language
Our contribution:
Definition of an AOP model for Web apps programming
Design and development of the simpAL-web platform
→ Which enables simpAL to deal with Web apps programming
3. Introduction
Web is becoming the deployment target de facto for new software systems
Ubiquity
Mantainablility
Open standards: HTML, CSS, ECMAScript, JSON
Several well known examples: Facebook, Google Docs, Gmail
Native (desktop and mobile) applications are moving to Web apps
Web standards are bridging the gap on usability and performance
→ AJAX: asynchronous interaction with (RESTFul) Web services
→ HTML5 new features: Web Workers, Web Storage, Offline Web Apps, ...
JavaScript is the lingua franca for Web apps programming
However it suffers of several problems:
Issues concerning in-the-large programming
→ Lack of structure and typing
→ Poorness of development tools
Issues concern asynchronous programming and concurrency
Compatibility
Security
4. JavaScript: improve or dismiss it?
JavaScript frameworks and libraries
DOM manipulation frameworks
→ jQuery
MVC frameworks
→ Backbone.js
Node.js
JavaScript as intermediate language
Toward structured Web apps:
→ Dart (Google)
→ TypeScript (Microsoft)
Evolution of the ECMAScript standard
→ JavaScript 6th Edition (Harmony)
5. Async programming
Event-loop architecture:
Widely adopted in GUI systems
Program’s control flow is determined by events
→ Handled through callbacks
Issues:
Asynchronous spaghetti
→ Application business
logic is fragmented
among event handlers
→ Matryoshka doll
programming style
(= callbacks +
anonymous functions)
Inversion of Control «I love async, but I can't code like this»
Web programming is strongly based on the Asynchronous paradigm:
→ User events from the Web page
→ Asynchronous requests to Web services
6. Promises / Futures
Problem: not always effective
→ How to model complex workflows, where the execution of a set of tasks
depends on the outcome of a previous task, with Promises?
Constructs to tame the Asynchronous
Spaghetti issue
Proposed in [1]
A Promise is a place holder for a
value that will exist in the future
Ability to chain or combine Promises
Web implementations:
→ jQuery Deferred-Promise
→ Dart Completer-Future
[1] Friedman, Daniel; David Wise (1976). "The Impact of Applicative Programming on Multiprocessing".
International Conference on Parallel Processing, pp. 263-272.
7. Concurrency
Based on the Actor-model:
Computational entities with
their own control flow which
interact by asynchronous
message passing
→ HTML5 Web Workers
→ Dart Isolates
Easily integrable with the
asynchronous programming
model
Issues:
Pure reactive entities: they do
something only in reaction to
the reception of a message
→ How to implement proactive
behaviours?
Heavy weight
8. AOP & simpAL
Agent-Oriented programming paradigm
Human-inspired computing
simpAL
General purpose AOP
Statically typed
Extension of OOP (Java)
Agents and Artifacts (A&A) conceptual model
Belief-Desire-Intention (BDI) architecture
simpAL main abstractions:
Agents
Artifacts
Workspaces
Organization
9. simpAL: Agent model & architecture
PlanDef :
'plan-for' TaskId
ActionRuleBlock;
ActionRuleBlock :
{ ActionBlockAttribute }
'{'
ActionRuleDef | BeliefDef [';']
'}';
ActionBlockAttribute :
'using:' Expression
{',' Expression}
| 'completed-when:' Expression
| 'atomically:';
ActionRuleDef :
WhenBlock '=>' AgentAction
| AgentAction {';' AgentAction };
WhenBlock :
( 'when' | 'every-time' )
EventTemplate [':' Expression]
| ( 'when' | 'every-time' )
Expression
| 'always';
EventTemplate :
'done' IdExpr | 'failed' IdExpr
| 'assigned' IdExpr
| 'told' Expression
| 'changed' Expression
Beliefs
Describe the agent’s internal state
Tasks
What agents have to do
Plans
How they do it
Collections of action rules
o Event : Condition → Action
o Possibly structured in blocks
o Syntactic sugar to enforce
sequentiality
Multiple plans for different tasks
Inter Agent comunication
Asynchronous message passing with
speach acts
Environment interaction
External actions
Percepts
10. simpAL: Agent execution semantics
Agent control loop
Sense stage
→ Processes an external event
→ Updates its belief base
Plan stage
→ Handles new tasks
→ Drops intentions for fulfilled
tasks
→ Selects all the actions
amenable to be performed
for ongoing intentions
Act stage
→ Performs all the selected
actions
11. simpAL-web
Requirements and assumptions:
Single-page web applications
Elements accessible by id
Perceive certain events from
certain elements
Access to element's content and
attributes
Structure of a simpAL Web app:
Separation of concerns
Web agents: encapsulating /
decentralizing the control logic of
the application
Web environment: integration with
low-level existing technologies
→ Built-in artifacts to handle the
Web page and its elements
→ Interaction with Web services
delegated to ad-hoc artifacts
12. Modeling the Web environment
WebPageArtifact
loaded: boolean
closed: boolean
⃝ getElement(id: String, elemArtifact:
WebElemInterface #out)
WebElemArtifact
clicks: int
doubleClicks: int
pressed: boolean
focused: boolean
pointerCoord: PointerCoordinates
keyPressed: boolean
key: int
⃝ getContent(html: String #out)
⃝ setContent(html: String)
⃝ getAttribute(att: String, value:String #out)
⃝ setAttribute(att: String, value: String)
Part of the environment which
model the interaction with the Web
page and its elements
→ Similar to the DOM APIs for
traditional languages
WebPageArtifact
→ Wraps the app Web page
→ Provide operations to access HTML
elements of interest, through
proper artifacts.
WebElemArtifacts
→ Wraps an HTML element in the
Web page
→ Provide operations to access
element’s content and attributes
→ Allow to perceive user events,
through observable properties
14. Interaction with Web services
Designing artifacts which model the Web
services themselves, in terms of:
Operations
→ To query or act on the services
Observable properties:
→ To perceive events or status
changes from the services
Allows to abstract from:
→ The concrete Web service implementation
→ The low-level logic needed to query the Web service
→ Operational restrictions due to HTTP
FacebookArtifact
lastFeed: String
⃝ getFriends(friends: List<Friend> #out)
⃝ getPhotos(photos: List<Photo> #out)
⃝ getEvents(events: List<Event> #out)
⃝ publishStatus(status: String)
How to enable simpAL Web 2.0 apps to asynchronously interact
with (RESTfull) Web services?
15. Async programming in simpAL-web
Native support for structured
async programming
Through ECA action rules
No callbacks
→ No Asynchronous
spaghetti
→ No Inversion of Control
Events
As changes in the Web
Environment state
→ Web page and elements
→ Web services
Tasks and labelled action
rules completion / failure
YouTubeArtifact
⃝ queryViewCount(search: String,
views: long #out)
16. Concurrency in simpAL-web
Do you remember the
JavaScript implementation?
This is the simpAL one!
Allows to integrate reactive and
proactive behaviours
Logic concurrency: virtually many
and many concurrent agents
→ Scalability
17. simpAL-web: implementation notes
Integrating the simpAL runtime with a custom Web browser
→ Built through the WebEngine and WebView JavaFx components
→ Based in turn on the WebKit open-source layout engine
18. Conclusions
simpAL-web pros
Asynchronous programming
→ No Asychronous spaghetti
→ No Inversion of Control
Concurrency
→ Mixing of autonomous and
reactive behaviours
→ Logic concurrency: virtually many
and many concurrent agents
→ Scalability
Software engineering and in-the-
large programming
→ Separation between interfaces and
implementations
→ Separation between active and
passive components
→ Modularity
→ Error checking at compile-time
Future works
Aim of our work was to lay the
foundations for the investigation of
simpAL as language for cliet-side
programming
→ NOT to replace JavaScript or
other reference technologies
Evaluate simpAL-web performance
Improve robustness and
integration with Web browsers
→ simpAL-web as plugin for
popular browsers (Chrome,
Firefox, etc...)
Sub-typing and inheritance in
simpAL: to model hierarchies of
element artifacts
L’obiettivo principale della mia tesi è stato di analizzare le tecnologie di riferimento e allo stato dell’arte per la programmazioni di applicazioni Web
In particolare per gli aspetti di complessità relativi a programmazione asincrona e concorrenza e i relativi problemi
A fronte di questi problemi, nella tesi abbiamo analizzato la possibilità di utilizzare un approccio orientato agli agenti per esplorare proprio se questi problemi si possano risolvere introducendo questo nuovo paradigma, e in particolare abbiamo considerato simpAL come linguaggio di riferimento per le nostre sperimentazioni.
Nello specifico partendo dagli aspetti di complessità analizzati e dallo studio in letteratura di certi paradigmi, il mio contributo è stato innanzitutto di pensare ad un modello Agent-Oriented per la programmazione di applicazioni Web, e quindi alla progettazione e implementazione del prototipo della piattaforma simpAL-web che ha lo scopo appunto di supportare questo nuovo modello di programmazione.
Una piccola nota: non ha a che fare con lo sviluppo Web in generale, come può essere quello di siti web, ma con la progettazione e lo sviluppo di Web app applicazioni distribuite fruibili via web
**
Cerchiamo innanzitutto di capire perchè questo tipo di applicazioni sta diventando sempre più diffuso.
Il web rispetto alle piattaforme di sviluppo tradizionali porta diversi vantaggi:
Primo tra tutti è sicuramente l’ubiquità, i web-browsers sono ormai dappertutto, sicuramente su tutti i pc ma anche nelle vostre tasche su smartphone e tablets.
Inoltre tutti i linguaggi e tecnologie per il Web sono standard, e sotto la supervisione del consorzio W3C
Quindi grazie a questi vantaggi il Web sta diventando sempre più il target per i sistemi software di nuova generazione, e le applicazioni standalone da una parte e mobile dall’altra stanno migrando verso il Web, basta pensare a noti esempi come Google Docs, soprattutto grazie al fatto che l’evoluzione delle tecnologie Web HTML5 e AJAX in particolare stanno colmando lo storico gap rispetto alle applicazioni tradizionali misurabile principalmente in termini di performance e usabilità.
Tuttavia JavaScript, che è l’unico linguaggio standard per la programmazione di applicazioni di questo tipo presenta diverse problematiche.
Soprattutto per quanto riguarda programmazione in-the-large, concorrenza e programmazione asincrona
E senza contare poi problemi come la compatibilità tra i web browser e sicurezza
A fronte di questi problemi si sta lavorando su diversi fronti, da una parte estendendo JavaScript con nuove librerie e frameworks, e dall’altra introducendo nuovi linguaggi come TypeScript e Dart che compilano su JavaScript e hanno l’obiettivo di portare struttura nelle applicazioni web principalmente attraverso classi e typing opzionale.
Parallelamente vi sono anche proposte per estendere lo standard JavaScript con questi nuovi concetti, ma questo percorso è ostacolato principalmente a causa della retrocompatibilità.
**
Lo sviluppo di Web apps al giorno d’oggi significa in buona parte dover gestire aspetti che si identificano come programmazione asincrona, che concernono ad esempio gli eventi dell’utente sull’interfaccia web e l’interazione con i servizi Web.
Il modello di riferimento per sviluppare applicazioni asincrone è l’architettura basata sull’event loop (che vediamo abbozzato in pseudo-codice di fianco)
In cui si programma l’applicazione andando a registrare callbacks ossia funzioni che vengo eseguite (dall’ambiente di esecuzione) al verificarsi di un certo evento
Tuttavia questo modello presenta diversi problemi, identificati in letteratura come Asynchronous spaghetti e Inversione del controllo
Spaghetti rievoca i problemi di programmazione derivanti dall’uso del GOTO prima dell’avvento della programmazione strutturata nel senso ke nella programmazione asingrona il flusso di controllo che rappresenta la business logic dell’applicazione è frammentato su tante callbacks
In javascript e negli altri linguaggi per la programmazione web, l’utilizzo di callbacks unito alla possibilità di definire funzioni anonime porta al cosidetto stile di programmazione a matrioska con piramidi nel codice come possiamo vedere nello script a fianco.
ATTENZIONE: questi problemi sono in realtà conseguenza del fatto che il paradigma ad oggetti non offre nativamente astrazioni di prima classe per modellare la programmazione asincrona.
Promises o Futures sono costrutti introdotti in letteratura per cercare di arginare il problema relativo all’asynchronous spaghetti,
Che mantengono callbacks che vengono richiamate al completamento di un’attività asincrona, e possono essere eventualmente accodate in cosiddette pipelines per linearizzare il flusso di controllo, per modellare workflow asincroni.
(Nell’immagine a finaco possiamo osservare lo script di prima implementato con Promises)
Tuttavia non sempre sono efficaci, ad esempio nel caso di workflow più dinamici (come quello modellato nell’activity diagram in basso) dove l’esecuzione o meno di un task dipende dall’esito di un task precedente
**
L’altro aspetto considerato oltre la programmazione asincrona è la concorrenza, ingrediente fondamentale per avere Web app le cui performance siano paragonabili alle applicazioni standalone tradizionali.
A tale scopo HTML5 con i Web Workers da una parte e Dart con gli Isolates dall’altra introducono componenti attivi basati sul modello ad attori.
Tuttavia anche questi presentano diversi problemi:
Il principale è sicuramente che essendo entità puramente reattive (fanno qualcosa solo in ricezione ad un messaggio) non riescono a modellare comportamenti autonomi o proattivi, come long term computations, a meno di trick.
A tale scopo consideriamo il caso di studio offerto dall’applicazione a fianco in cui abbiamo un attore che rappresenta il flusso di controllo (indipendente da quello della pagina) che deve ciclicamente incrementare una variabile e mostrarla sulla pagina, rimanendo reattivo alla pressione dei pulsanti start e stop.
Lato attore, Dato che non possiamo avviare un ciclo infinito per l’incremento (che determinerebbe la perdita di reattività rispetto al click dello stop)
Il trucco che di solito si usa in questi casi è di auto-inviarsi un messaggio (per la prosecuzione di una certa attività)
***
Una volta analizzate queste problematiche abbiamo pensato di affrontarle introducendo il paradigma di programmazione Agent-oriented, che si richiama metaforicamente alle organizzazioni umane
E simpAL come linguaggio di riferimento ke, a differenza di linguaggi ad agenti e multiagente nel contesto AI, si propone proprio con l’obiettivo di sperimentare questo tipo di paradigma per la prog. general purpose
A tal scopo ha una nozione di tipo statico
E può essere visto come estensione del paradigma ad oggetti, Java in particolare, che è utilizzato per la rappresentazione di strutture dati e relativi algoritmi
I concetti fondamentali su cui si basa simpAL vengono da modelli concettuali ed architetture proposte in letteratura in particolare Agent&Artifacts e Bilief-Desire-Intention
Secondo questi modelli:
Un programma o organizzazione simpAL è costituito da un insieme di agenti che sono entità autonome e modellano i componenti attivi dell’applicazione, programmati per svolgere compiti e che operano all’interno di un certo ambiente. L’ambiente è modularizzato in termini di artefatti su cui gli agenti agiscono tramite azioni e che osservano. Inoltre dato che il programma può essere distribuito viene introdotta la nozione di spazi di lavoro per definire delle località.
**
Un agente è strutturato in termini di
Tasks che indicano i compiti che un agente è in grado di svolgere
Piani che descrivono le azioni che l’agente può compiere per svolgere un determinato compito.
E una Belief base, che rappresenta le strutture dati necessarie per mantenere lo stato interno dell’agente
Come possiamo vedere dalla grammatica a fianco, Un piano è definito da un insieme di regole chiamate action rules del tipo Evento, Condizione, Azione, che portano a poter descrivere un comportamento sia reattivo che proattivo, e praticamente descrivono quando fare cosa. Queste possono essere strutturate in blocchi in modo da organizzare e modularizzare meglio il piano stesso.
Un agente può avere più piani per compiti di tipo diverso
Questo invece è uno script di esempio che mostra come sia possibile codificare il comportamento di un agente in termini di task e piani, e i piani a loro volta in termini di blocchi di action rules
La semantica operazionale che descrive il comportamento complesivo dell’agente è data invece dal ciclo di controllo.
Il ciclo di controllo è strutturato in tre fasi: sense / Plan / Act che vengono ripetute continuamente
Questo E’ il nocciolo dell’architettura simpAL, Sempre ispirato dalle architetture BDI,
E che permette effettivamente di integrare un reattività e proattività e quindi consente di ottenere comportamenti volto al raggiungimento di un obiettivo e contestualmente reattivo ai cambiamenti nell’ambiente
***
Data un infarinata sul paradigma di programmazione ad agenti e simpal
Passiamo ora ad introdurre il nuovo modello che proponiamo per la progettazione e lo sviluppo di applicazioni Web in simpAL
Innanzitutto introduciamo una serie di vincoli e assunzioni sul dominio delle possibili applicazioni Web, allo scopo di identificare un’insieme di funzionalità essenziali che saranno poi quelle offerte dalla nostra piattaforma di sperimentazione. Ossia:
Applicazioni a singola pagina, elementi accessibili attraverso id, possibilità di percepire solo determinati eventi, dai soli elementi HTML di interesse per l’applicazione e possibità di accedere e modificare contenuto e attributi di questi elementi.
Sulla base di questo, L’idea fondamentale come possiamo vedere in figura a fianco sarà di avere applicazioni simpAL-Web strutturate in termini di:
Agenti per incapsulare e decentralizzare la logica di controllo applicativa, in particolare quella che dovremmo attribuire a componenti attive.
Questi agenti saranno situati nell’ambiente web che sarà quindi costituito in termini di:
Artefatti bult-in per l’interazione con la pagina web ed i relativi elementi
Artefatti sviluppati ad-hoc per modellare l’interazione con i servizi web
Come vedremo in seguito programmare applicazioni web in simpAL secondo questo modello ci consentirà di
Gestire in modo naturale la programmazione asincrona
Gestire ad un più alto livello di astrazione gli aspetti che concernono la concorrenza
Quindi andiamo ora a progettare gli artefatti in termini di operazioni e proprietà osservabili, sulla base delle assunzioni fatte e sulla base delle azioni che quindi gli agenti delle applicazioni simpAL web potranno voler eseguire.
Quindi innanzitutto un artefatto che rappresenta la pagina web, attraverso cui gli agenti possono osservare lo stato della pagina stessa, e reperire, attraverso l’operazione getElement gli artefatti che modellano gli elementi HTML su cui l’agente sarà intenzionato ad agire, o osservare.
E poi l’artefatto elemento, attraverso cui è possibile andare ad agire su uno specifico elemento html e percepirne gli eventi, che, ATTENZIONE sono modellati come cambiamento di stato di proprietà osservabili.
Introdotti questi elementi possiamo già andare a vedere come implementare la più banale applicazione Web che ci venga in mente, in cui (laser) l’agente una volta caricata la pagina, va a reperire gli artefatti che modellano gli elementi relativi al bottone ed al div di output
Dopo di che, da notare il punto e virgola che non è altro che zucchero sintattico per imporre sequenzialità tra due action rules, va a scrivere sulla pagina «push the button»
E, quando il bottone viene cliccato, stampi l’ «hello world»
Da questo semplicissimo esempio possiamo già vedere due cose:
Da una parte come la programmazione asincrona sia gestita in modo naturale attraverso le action rules
E dall’altra come sia possibile nello stesso piano integrare una parte di azioni, quindi un comportamento proattivo, e una parte di reazioni
Come già detto una parte dell’ambiente web sarà costituita da artefatti che modellano l’interazione con i servizi web.
Questi artefatti saranno progettati in termini di
Operazioni: ad esempio per interrogare il servizio
O proprietà osservabili che consentono invece di percepire eventi dai servizi stessi
Questo ci permette di astrarre lato agente
Dall’effettiva implementazione del servizio web
Dalle logiche di basso livello richieste per interrogare il servizio
In alcuni casi a prescindere addirittura dalla natura del protocollo HTTP stesso
Un esempio può essere dato dall’artefatto la cui interfaccia è mostrata in figura e che modella l’interazione con il servizio Facebook.
Come possiamo vedere oltre ad operazioni che servono ad esempio per ottenere la lista di amici e pubblicare un nuovo stato,
C’è la proprietà osservabile lastFeed attraverso cui un agente può osservare ed reagire rispetto all’ultima attività pubblicata in bacheca,
In modo molto naturale, Proprio come se l’agente stesse consultando la sua bacheca facebook,
Chiaramente dato che HTTP non supporta l’operazione PUSH lato server sarà l’artefatto che a polling, con un certo intervallo, andrà ad interrogare effettivamente il servizio facebook
Premessa: Detto questo entriamo nel merito di come avviene la programmazione di applicazioni web in simpAL in particolare per quanto riguarda gli aspetti di complessità visti prima
In particolare, come poi già accennato prima, simpAL fornisce astrazioni di prima classe per gestire la programmazione asincrona in modo strutturato, attraverso le action rules. Questo permette quindi di risolvere radicalmente i problemi introdotti dal modello a callbacks, ossia asinchronous spaghetti e inversione del controllo.
Gli eventi inoltre possono essere relativi a cambiamenti di stato nell’ambiente web, come già visto prima)
O relativi al completamento o failure di task o action rule
Come possiamo vedere nell’esempio a fianco dove il servizio youtube viene interrogato con due richieste diverse e il blocco when permette di reagire solo quando entrambe le richieste sono state completate con successo, grazie a is-done associata all’etichetta della rispettiva action rule
Per quanto riguarda la concorrenza invece il grande vantaggio portato dal paradigma ad agenti e simpAL riguarda la capacità di integrare comportamenti autonomi e reattivi.
In questa slide abbiamo riportato l’esempio del contatore javascript con web worker visto prima implementato questa volta simpAL attraverso questo piano in cui viene espresso in modo molto naturale che quando il pulsante start viene cliccato viene attivato il blocco repeatedly che rappresenta la parte attiva dell’applicazione in quanto in pratica è un ciclo che continuamente incrementa e stampa il valore della variabile; il comportamento reattivo è espressa grazie dall’attributo completed-when che determina la terminazione del blocco repeatedly non appena il pulsante stop viene cliccato.
simpAL inoltre a differenza dei Web Worker di html5 supporta la concorrenza ad un più alto livello, nel senso che il mapping degli agenti sui thread fisici del sistema operativo è gestita automaticamente dal runtime di simpAL, questo permette di avere anche un numero elevato di agenti in un’applicazione con un buon grado di scalabilità.
Infine per dare un accenno all’implementazione effettiva della piattaforma simpAL web
Il diagramma uml in figura mostra nella parte di destra gli artefatti pagina ed elemento in simpal mentre nella parte di sinistra l’applicazione basata su JavaFx che funge da Web browser
Il livello software al centro è un invece un estensione al runtime di simpAL che consente da una parte di mappare gli eventi del Web browser su cambiamenti di stato in prop. Osservabili lato artefatti e far si che le operazioni richiamate sugli artefatti stessi vadano a modificare l’effettivo contenuto della pagina web mostrata nel browser
***
In conclusione grazie alle astrazioni di più alto livello offerte dal paradigma Agent-oriented e simpal abbiamo visto come poter affrontare i problemi che oggigiorno affligono Javascript e la programmazione di applicazioni Web
Sia per quanto riguarda la prog. Asincrona
Che per quanto riguarda la concorrenza
Inoltre simpAL apporta anche vantaggi relativamente alla programmazione in-the-large: Modularità, error checking a tempo di compilazione grazie al typing statico e separazione: tra interfacce ed implementazioni e tra componenti attivi e passivi
Dato che lo scopo principale di questo lavoro è stato porre una base per l’esplorazione di Agent-oriented programming e simpal come strumenti di sviluppo per la programmazione web, e la piattaforma sviluppata è di conseguenza un prototipo, ci sono questioni che rimangono aperte
Come il rapporto delle performance rispetto ai linguaggi mainstream
Oltre che questioni relative alla robustezza e integrazione con i browser
Sviluppi futuri potrebbero essere diretti all’implementazione della piattaforma come estensione di uno dei comuni browsers