Domain Change! from bd-things.net to task3.cc

March 18th, 2010 bodom_lx No comments

As you may have noticed, I’ve just changed domain name! My website/blog has faced its third domain change in 5 years. The flow has been the following:

daniel.graziotin.net -> bd-things.net -> task3.cc

I decided to switch to task3.cc because I already owned the domain. Moreover, task3.cc has a nice story behind and is more Computer Science oriented than the Web2.0 bd-things.net name.
I hope that this will be the last domain change ever!

Related posts

Categories: Blog Tags: , ,

On the protocol adopted by Dycapo

March 17th, 2010 bodom_lx 3 comments

It took us more than two months of discussions in order to decide which protocol to adopt for procedure calls in Dycapo.

As we are trying to extend an existing XML-based protocol, the first solution we took in consideration was to implement a remote procedure call protocol based on OpenTrip. That is, directly passing OpenTrip objects over HTTP methods.

Unfortunately, the most elegant solution immediately appeared as unsuitable for those reasons:

  1. It is against the DRY principle, as there exist many other RPC protocols out there
  2. A new RPC protocol implies the creation of new parsers and utilities for (Un)Marshalling data: nobody would write a client for Dycapo if he/she has to implement everything else from scratch
  3. OpenTrip is at a “0.1 draft” status. It may change very often in the future. I would not have the time to create and update parsers and utilities while developing Dycapo.

Therefore, we took the decision to adopt OpenTrip entities and propose OpenTrip Dynamic over some existing protocol. We looked at REST, XML-RPC and SOAP.

REST was seriously taken into consideration, as it is successfully used by Flickr, Delicious, Yahoo and Twitter (and many others). Even if it is not a protocol, it permits to define coincise locations for resources and imposes some rules on the vocabulary used, creating self-descriptive messages. Moreover, there are many Django extensions that support REST.
Unfortunately, I could find more reasons against the adoption of REST than in favor:

  1. It is NOT a protocol but an architecture, or a set of conventions. Therefore, it does not define a format for data exchange. There exist SON, YAML 1.0, YAML 2.0, arbitrary XML formats. Every successful REST-ful WS either defines its own XML format or provides support for all these formats. We would like to be completely architecture independent. Therefore we need a strong data exchange format in order to handle our quite complex objects sent and received by and from clients.
  2. REST is a Resource-Oriented Architecture. Everything is thought around representation of resources. Dycapo implementation would fit with difficulty in this way of thinking. A Service-Oriented Architecture fits our needs and way of thinking.
  3. It may still require a lot of work on the client side caller of the library to make use of data (custom serialization and so forth)

We are not aware of any successful application using REST that needs to pass around complex objects. For example Flickr specifies which parameters must be passed to methods and their format. See an example on this API page.
Our goal in adopting OpenTrip objects was to don’t worry about parameter passing but to just have OpenTrip objects defined in the client, in the server and also inside the databases they keep. Therefore, to have universal objects that can be passed around as parameters.

Regarding XML-RPC and Soap, we know that they are very similar (first drafts of Soap were about XML-RPC with namespaces). After analyzing both of them, we agreed on the adoption of XML-RPC because

  1. It is lighter than SOAP: you just put objects/method calls encoded in XML in HTTP methods. SOAP adds overheads by using namespaces, envelopes, a header, body and fault sections.
  2. It exists since 1998.It is supported by all modern mobile devices, from iPhone to Android to Symbian. Moreover, its data exchange and message formats are very simple. It would be easy even to write a library from scratch. As an example, look at how tiny and simple is android-xmlrpc. SOAP is not widespread on mobile devices as XML-RPC is. Its complexity is also a barrier to write libraries and parsers.
  3. XML-RPC permits us to exchange quite complex objects regardless the implementation of server and clients. It has many data types already available. In particular our OpenTrip objects passed as parameters surely contain arrays and structs. An example could be an array of 4 Locations as part of a Trip object. In Rest we would have needed to decide how to marshall arrays into parameters, and developers would have needed to create their own parsers and serializers.
    Marshalling of data is often possible with XML-RPC. Developers just have to look at our method signature and object structure and forget about the RPC structure and formats. Everything should be automatically handled by existing libraries

We did some tests with available XML-RPC libraries for Java (also Android) and Python (Django). We found that marshalling and unmarshalling of OpenTrip objects is possible, i.e. objects can be serialized and passed via XML-RPC by django and received and deserialized by Java with none or little adjustements.

As a tiny example, look at the following code. It is a snippet of the current method call when searching for a ride. I just included the generated XML-RPC for the second parameter, as the first one is an object of the same type.

dycapo.search_trip ( Location source , Location destination )

< ?xml version=‘1.0′?>
<methodcall>
  <methodname>dycapo.search_trip</methodname>
    <params>
      [..]
      <param>
        <value>
          <struct>
            <member>
              <name>georss_point</name>
              <value><string>1.0,1.0</string></value>
            </member>
            <member>
               <name>point</name>
               <value><string>dest</string></value>
            </member>
            <member>
                <name>leaves</name>
                <value><string>2010-03-12 14:36:54.772156</string></value>
            </member>
            <member>
                <name>label</name>
                <value><string>office</string></value>
            </member>
          </struct>
        </value>
      </param>
    </params>
 </methodcall>
 

See how simple and elegant it is? We are simply passing an object, represented as a struct, with 4 attributes:

  • georss_point: “1.0,1.0″
  • point: “dest”
  • leaves: “2010-03-12 14:36:54.772156″
  • label: “office”

Don’t try to reason about types, names and quality: we are still experimenting.

Related posts

Updated UML diagrams for Dycapo

March 5th, 2010 bodom_lx No comments

I’ve just finished in re-writing/updating the UML diagrams of Dycapo.

We now have an updated version of the models, that are now consistent with those in code.

There are three new sequence diagrams useful for using Dycapo:

  • Insertion of a Trip by a driver
  • Search of a Ride by a rider
  • Insertion+Search of a Trip together, with the right time of operation

The sequence diagrams are also consistent with the code and tests.

Diagrams can be found in the docs/ directory of the project, or can be browsed directly in the new Design page in the wiki.

Enjoy!

Related posts

What comes next? Short run roadmap

March 2nd, 2010 bodom_lx No comments

The second part of my internship has just begun. I spent some hours to think about what will be next in Dycapo development, in a short run.

A CS school mate joined the project. He will write a client for Dycapo using Android. Moreover, I will write my thesis on this project.
Therefore, there is a strong demand for documentation here. I also hope that someone joins the project.

Here is a short run to-do list for Dycapo:

  • Update all the UML diagrams (class diagram, add new sequence diagrams)
  • Write a short post about the decision of using XML-RPC as communication protocol
  • Update the existing methods to use the new features provided by RPC4Django
  • Write and export a first draft of documentation to be used as API

As you can see, there are no plans to add something new to Dycapo yet. I would like first to build a strong working base, even if lacking functionalities. More features will be added afterwards.

Moreover, I will begin to use SemVer versioning system.

Related posts

Dycapo Development Resumes

March 1st, 2010 bodom_lx No comments

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.

Related posts

Announcing Pomodroid 0.4.3, some big changes

February 24th, 2010 bodom_lx No comments

The fourth public release of Pomodroid brings some new features and corrections:

  • Fixed bug when rotating the device under a running Pomodoro. Pomodoro Activity is forced to stay in portrait mode
  • Bigger Pomodoro Timer
  • Pomodoro.java completely rewritten. Makes use of Handler and Runnable instead extending CountDownTimer
  • Notification system completely rewritten: user is notified through real Notifications, vibrations and Toasts.
  • The new notification system is also used in PomodroidException.java

The apk is already in the Market.
Everything else can be found in the official project page.

Related posts