Proposed By: Shilpa Onkar Singh and Govindaraju SM
We use multiple text services like spellchecking, translation, synonym, grammar etc. on a day to day basis either via text editors or translation tools or internet. While reading or writing, if users require any type of text service which is not part of application like for e.g. translation, synonym etc. have to copy, paste the word to a browser/tool and get the service. All text services are scattered across tools, web etc. Application developers, to incorporate all these services need to create application using different libraries and different interfaces. To solve the above problems, we propose common framework design which brings many types of text services together and is easily extensible to add many more text services as well.
People use multiple text based services in their day to day life, generally these services are scattered around, for spell checking and correction, grammar checking and correction text editor tools. For translation, translation tools or web and for synonym or meaning, dictionary tools etc.
For devices like smartphones, tablets which have multiple applications the above text services requirement is common and only few of them are available as part of an application. The available services are present in different libraries each with their own design and APIs.
Let’s take a use case, user is reading an email but email has some different language strings, some difficult words whose meaning is not known. If “in app” help is not available user has to use tools, web by copying pasting the word and understanding the meaning. Alternatively when user is typing an email, they will need “in app” help for spell, grammar check.
Let’s say that multiple text services are available as part of a framework with simple usability and easier extensibility, any app can connect to framework and avail all these services using a simple and common interface and provide these services as “in app” help simplifying user’s usage of these services. In addition, all data required by framework need not be in the same device and can be accessible by cloud giving the feeling to the user that all information needed is available on device itself. We propose to make such a kind of common framework for easier access of all kinds of required text services.
The proposed architecture is based on client, server communication model, the server is a daemon process which runs and gets initialized with the initial access of the text service by client (explained later). All text services are accessed in an asynchronous manner and a context is maintained between each client and the server which contains all the data needed by server from client like for e.g. Current locale, maximum number of response candidates, whether service can be availed by cloud or local only based on authentication given by user etc. Context is stored both at client and server level because even if connection is lost for some reason, client should be able to restart the session again based on stored context.
There are three primary parties involved in the text services framework (TSF)
- Client: These are applications which arbitrate with text service manager using client wrapper APIs and communicate with text services.
- Text Service Daemon: It’s a daemon process which is divided further in to three blocks.
- Client Wrapper: Set of APIs which abstract the IPCs
- Text services manager: This is the central part of system which manages client connections and delegates the request to the corresponding text services handlers.
- Text service Handler: These are service based handlers which allow the client application to retrieve information about text.
- Plug-ins: These are the specific library based modules which implement various interfaces provided by handlers.
Fig.1. is the architecture diagram for the above proposed model.
Fig. 1. Architecture of Text service framework
From above architecture we can understand that for a particular service we can have multiple plugin’s and the plugin’s can be located locally on the device or can be a cloud based plug-in.
When a request is sent from client for a particular service, the request is sent to corresponding service based handler which sends the request to plugins handler, plugins handler transfers this request to all plugins registered for that particular service, multiple responses is received by all plugins and these responses are consolidated to a single response based on priority by service handler and sent to client. Fig.2 architecture diagram shows the same.
Fig. 2. Single consolidated response from a service handler
Following sequence diagram indicates the interaction between application/Text Widget, Text service manager and
Create Ecore_Text Directory some what similar to Ecore_Audio which has two parts, A Text service client wrapper library (application will avail the various text services using the provided APIs in this library) and a text service manager/daemon (central part of the system which manages client connections and delegates the request to various handlers)
- Ecore_Text_Client (.so library - client)
- bin (daemon process - server)
- spellchecker plugin (module functions which interact with actual spellcheck library like enchant)
- translation plugin
- transliteration plugin
Based on tested prototype we can infer that though due to IPC there is a slight delay in response, the delay is still acceptable for text service based use case. But as we propose daemon process architecture, we will not have any extra RAM consumption per client application, memory can be further saved if plugins are cloud based but with a tradeoff of delay in response. Underlying plugin libraries can always be changed without having the need to change application code; multiple plugins usage will provide more accurate response and also, other benefits of opening up new opportunity of Text Service Commercial plug-in support for devices like Smart Phones and tablets. Hence making this architecture desirable.