GSoC 2015 : Week 5

This post is regarding the work done in the fifth week of the GSoC coding period. To know more details about the project follow the Introduction link.

It’s time for the midterm evaluation and I am running as per my timeline..! So I need not worry about it. 😛

This week I added some new features to the replicator and modified the code written for the couchdb-client, mostly involving removal of unnecessary commits and addition of tests, in order to make it suitable for pull request. The PR is yet to be merged and can be seen by following link [1].

Last week I had experimented on the streaming docs with attachments. This week I added the logic to the couchdb-client as a new MultipartClient which reads data from the source in chunks, processes it and transfers it to the client with desired modifications. It’s not very general now and supports only streaming the multipart  response from the source to the target. It will be modified as per the feedback of the maintainer of the couchdb-client and it will be done after I get the first set of changes merged. The multipart client and other set of related changes to use the MultipartClient can be seen by following the link [2].

The replicator now supports the continuous replication, which means that once a replication has been started started, the replicator-source and replicator-target connections will not end after the set of changes has been transferred. They will remain connected  and as soon as any change involving insertion, deletion or modification happens at the source, it will be transferred to the target. It has two variants, first where the replication never stops and a periodic heartbeat is sent continuously and the second where a max timeout can be set for waiting to close the connection before sending the response. Currently only the source-replicator connection remains opened.  The changes to support this can be seen by following the links in [3].

Now in the current week, I don’t plan to add any new features or to start the Drupal related part with writing Drush plugin. I will be mostly writing tests which my mentor greatly emphasizes upon 😛 , for the client and replicator. Also making changes to the client for the PR is another thing that I will work upon.

Links:

1. couchdb-client/pull/42
2. couchdb-client/tree/trying_generators/lib/Doctrine/CouchDB
3. 1. replicator: couchdb-replicator/tree/continuous_replication  ,
   2. client: couchdb-client/tree/continuous_replication/lib/Doctrine/CouchDB

GSoC 2015: Content Staging Solution for Drupal 8

Introduction

Hi folks..! I am Abhishek Kumar, a CSE 2011 student of IIIT Hyderabad. This post will give updates about the work going on in my Google Summer Of Code 2015 project, which is being done under Drupal. Dick Olsson (dixon_) and Christian López Espínola (penyaskito) are my mentors for the project. The project is about content staging which is a highly desired feature in many circumstances. For example, where the content is developed inside a firewall protected network and then is pushed to the production site, and where content is being edited in separate development sites and staged to a central site. There are various issues involved in content staging and it is not straightforward. Content may have dependencies like authors and tags which also need be transferred when the content is replicated. There are also setups where a content workflow might cause conflicts between revisions of content, which needs to be handled by the system. The various modules for this system are under active development for Drupal 8. For example:

• Multiversion module which extends Drupal’s content storage and revisioning model as well as handling update sequences for easier dependency management (unlike existing entity dependency module for Drupal 7 which recursively builds a complicated graph).
• Relaxed Web Services module which is exposing Drupal content over a REST API that follows the same specification as CouchDB.
• Deploy module which provides a UI.

These modules are not yet complete and are constantly evolving. Another important component of the system is the replicator which is responsible for transferring changes from the source site to the target site. Handling both the module development and implementing the replicator seems to me that it will not be possible within the GSoC period of 3 months, as the involved modules (multiversion) needs to deal with complex issues. Working on modules with the rest of community will be a filler task, as of now. So, my gsoc project is to develop the replicator, which:

1. Will be a stand-alone PHP library.
2. Will be based on the CouchDB replication protocol.
   1. Concise description: link
   2. Detailed description: link
3. Will not depend on Drupal 8. The source and target of the replication can be any system that implements the CouchDB API specification.
4. Initially, will be built and tested with CouchDB endpoints, due to the Drupal modules still being in development. In the 2nd half of the GSoC period the replicator will be tested with the Drupal modules to complete the full content staging solution.
5. Will be integrated into Drupal with a Drush plugin.
6. Will get a simple Drupal module with UI for managing replications.
7. Will have full unit test coverage.

To know more about the work in this direction see this video of a presentation given by Dixon at DrupalCon.

---

Link to weekly blogs

Each week I would be writing a blog post describing the work done in that week. Use the links below to access blog posts for the work done till now.

1. Week 1
2. Week 2
3. Week 3
4. Week 4
5. Week 5
6. Week 6
7. Week 7