bodom_lx at task3 dot cc|

Dycapo v0.2.0 is out.

This is the second version exiting the “proof of concept” releases. This version adds lots of improvements and enhancements. As I announced four days ago, Dycapo Server now supports what we published up to now regarding Dycapo Protocol. The Protocol specification regarding entities is hopefully complete, give it a read!

The following are the release notes:

RELEASE NOTES
***************
2010-04-21  Daniel Graziotin  

Dycapo v0.2.0 is the second prototype version on which we are beginning to build our APIs.

Dycapo v0.2.0 incorporates and shows:
* Adoption of Dycapo Protocol [http://dycapo.org/Protocol]
* The introduction of API [http://dycapo.org/Server/API]
* Integration of Dycapo models with Django models
* Authentication system
* Insertion of a trip by a driver
* Start of a trip by a driver
* Search of a trip by a rider
* Send a ride request to a driver
* Let the driver accept the ride request
* Geolocation methods of Persons
* A complete testing framework

CHANGES SINCE v0.1.0
***************
General:
* OpenTrip left out for Dycapo Protocol (which is based on OpenTrip anyway)
* Added reStructured Text [http://docutils.sourceforge.net/rst.html] documentation in XML-RPC methods 

server/utils.py
* Methods regarding OpenTrip ids deleted

server/common.py
* Added Geolocation methods for Persons: update_position() and get_position()

server/driver.py
* Methods updated to support Response objects also in case of some errors

rider.py
* Methods updated to support Response objects also in case of some errors

server/models.py
* Dycapo Protocol [http://dycapo.org/Protocol] fully adopted
* All to_xmlrpc() methods now use copy.deepcopy() for safe object.__dict__ copy operations
* WAYPOINT_CHOICES now has 'posi' attribute, to indicate that a Location is representing the
  position of a Person
* Deleted 'intersection' and 'address' attributes to Location (redundancy reasons).
* Deleted all attributes regarding GeoRSS but georss_point
* Added geocoding and reverse geocoding methods to Location (using Geopy)
* Added functionalities to avoid redundancy when trying to add Location objects
* Deleted 'alias' and 'userid' attributes to Person (redundancy reasons)
* Deleted 'content' attribute in Trip. It was a String, now it is just returned when
  constructing xml-rpc representations of Trips
* Added has_vacany() and update_vacancy() methods to Trip
* Added requested_position, accepted_position, started_position, finished_position
  attributes to Participation, that will hold the position of the user when he/she
  does Participation operations (safety reasons)

I just finished to write the specification of the Entities of Dycapo Protocol. Each entity is now fully described and every attribute has a correct XML-RPC type and the requirement level specified.

It is now time to make Dycapo Server reflect Dycapo Protocol.

Remember that everything could change up to Dycapo Server v1.0.0.

I am preparing a new release of Dycapo Server. The new version will include some bug fixes but many improvements.

For now on, I am working on

• Adding new fields to Participation objects, for improving safety of people
• Adding RPC methods regarding the current position of people
• Improving the returns of Trips

The new release, that is scheduled around the end of the next week, will also have a major update in the documentation. I would like to improve the Protocol section to add real tables of the exchanged objects. Also the first APIs will be written.

Dycapo is the project I'm developing for my Bachelor thesis in Computer Science, during my internship at Fondazione Bruno Kessler, in the SoNet research group.

Dycapo Project mission is to develop a complete free/open Architecture to provide Dynamic Carpooling capabilities. That is, Dycapo Project outputs will be:

• A Protocol aspiring to become a standard for Dynamic Ridesharing services
• A Server System implementing the Protocol, providing a full Dynamic Carpooling system
• A set of API to access the service
• A mobile Java client for Android smartphones

The first three aspects are developed by me, while the fourth one will be written by a Unibz collegue.

Because Computer Scientists are lazy, we gave very simple code names to every part of the Project:

• Dycapo Project is the whole ambitious project, including the whole Architecture, the research activities and people behind
• Dycapo Protocol is the Dynamic Carpooling Protocol that I am writing
• Dycapo is the server system implementing Dycapo Protocol

The whole project has its home located at http://dycapo.org

Dycapo v0.1.0 is out. This is the first version exiting the "proof of concept" releases. From this one, we are beginning to build our APIs, that will soon be published in the project wiki.

Dycapo will be an open client (mobile)/server system that will improve travel experiences of users in a city. The system will let people to define a destination on their mobile phone. DyCaPo will suggest and arrange trips by either using the Public Transport Service or Carpooling volunteers.
That is, DyCaPo will implement full Dynamic Carpooling functionalities as well as static approaches.

More information and download on the official page.

Here are the release notes and the changes since 0.0.2:

RELEASE NOTES
***************

2010-04-03  Daniel Graziotin  

Dycapo v0.1.0 is the first prototype version on which we are beginning to build our APIs.

Dycapo v0.1.0 incorporates and shows:
* The introduction of an open Protocol heavily inspired by OpenTrip Core [http://www.opentrip.info] based on XML-RPC calls
* Integration of Dycapo models with Django models
* Authentication system
* Insertion of a trip by a driver
* Start of a trip by a driver
* Search of a trip by a rider
* Send a ride request to a driver
* Let the driver accept the ride request
* A complete testing framework

CHANGES SINCE v0.0.2
***************

General
* sqlite no more included, we make use of MySQL for testing (dump is included)
* docs/ directory is cleaner
* SemVer [http://semver.org] adopted
* Refactoring
* Return values adjusted thanks to new Response object, now used eveywhere
* Use of get_xmlrpc_user() and new RPC4DJANGO feature to get the logged in user

tests/:
* Use of the new Response object
* More verbose, clearer
* Refactoring
* Can be configured throught a file, settings.py

server/models.py
* New Response object, the default returning value of every XML-RPC call. Acts as an Envelope, like in Soap.

server/response_codes.py (NEW)
* Contains the default codes and strings to be returned from Response objects

server/utils.py
* util function get_xmlrpc_user(), that returns the Person object making the XML-RPC call

server/rider.py
* Better documentation

Dycapo development resumes from today. I'm going to write a tiny plan to point out the status of the project and what we are going to do next. Meanwhile, a new member joined SoNet and the project, to develop an Android client for Dycapo. Stay tuned for news.