From Dycapo Project
THIS PAGE IS A WORK IN PROGRESS.
In this page we describe our plan and strategy. Our strategy consisted of three phases, described below.
Contents |
Research Phase
During this phase we acquired the knowledge base necessary to model in the domain of interest. We also gathered useful information and requirements. After this formal phase, we decided what we could do and how to do it.
The following are the steps we made:
- Review of existing papers, comparison with "Current trends in Dynamic Ridesharing, Identification of Bottleneck Problems and proposition of Solutions" by Hannes Zimmerman and Yann Stempfel
- Review of existing web and mobile applications, comparison with "Current trends in Dynamic Ridesharing, Identification of Bottleneck Problems and proposition of Solutions" by Hannes Zimmerman and Yann Stempfel
- Review of protocols
- Research about the motivations of failure/success of existing realities
Action Phase
After the Research Phase (see also the Research/Outcomes page) we decided to move as follows.
Protocol
World is missing a standard, open protocol for communication between Dynamic Ridesharing applications OpenTrip is a very good attempt but it seems stationary to the definition of the data format. Moreover, we did not have time and resource for implementing a server system supporting it. Therefore we decided to study its entities, extend them and implement the missing operations using an XML-RPC based protocol. The reasons are the following:
- XML-RPC is the most supported RPC protocol by programming languages and mobile phones
- It is easy to implement libraries for (un)marshalling data, if missing
- We wanted to quickly develop a prototype server to demonstrate our protocol
- See also this article on the website of the author of Dycapo Project for more information
Dycapo Protocol is our attempt to define a common, standard protocol for Dynamic Carpooling applications.
Our future plans are:
- To have a stable and working XML-RPC based protocol
- To have a fully working server prototype implementing the protocol
THEN:
- Convert our extended entities back to OpenTrip Core format (basically Atom) as we are almost compatible with all their names and relations
- Convert our Protocol operations to RESTful operations compatible with OpenTrip Core format (therefore AtomPub, OData)
- Push our Standard to the world
API
The API are well documented and:
- Are useful for who is implementing a client for Dycapo Server
- Are a temporary substitute for the operations of Dycapo Protocol
TO-DO: add a link to the new API
3. Adoption phase
TO-DO