this is the original text of the project proposal. As I have been accepted, I will use DanielAbel/GsocProject to kepp up-to-date information about my project

Daniel Abel's Google Summer of Code 2008 project proposal (draft)

As my google summer of code project, I propose to merge two features that have been on the cytoscape whishlist for a long time, and for which I already have working implementations in a fork of an older version of cytoscape. These were not yet merged into core cytoscape because some aspects involve changes to large parts of the codebase. In addition, they also involve some (but pretty small) API changes, so seem more appropriate for the upcomming cytoscape 3.0 than for previous point-releases.

1) implement edge directionality.

Currently cytoscape handles all edges as directed. Even though the libraries cytoscape uses (giny, etc.) can handle undirected edges, this fact is hidden by the gui. Due to this limitation, users can only handle directed edges.

I propose to implement undirected edges as 'first-class citizens' i.e. on equal footing with directed edges. I have a working implementation of this for cytoscape 2.4, so the work I am proposing to do as part of my google summer of code project is not to implement this feature, but to port an already working implementation to the current development version of cytoscape,version 3.0, and to merge it into the core cytoscape codebase.

see: UndirectedEdges and thread on cytoscape-discuss

Because core cytoscape libraries already handle undirected edges, and because I already have a working implementation, this part of my proposed summer project should be reasonably simple, taking 2 weeks at most.

Implementation plan:

• fix backend part (i.e. API and XGMML import / export) (about one week)

• gui fixes (for example vizmapper so that it will treat both ends of an undirected edge the same, and TableImport so that edge directionality can be specified when importing) (about one week)

2) Implement local attributes

This is a long-standing cytoscape whishlist item. (see LocalAttributes and Network_specific_node_and_edge_attributes)

Apparently the current plan by cytoscape core developers is to implement local attributes using the planned 'attribute namespaces' feature (see AttributeNamespaces) however, the 'attribute namespaces' and 'local attributes' features are semantically different and trying to implement local attributes with attribute namespaces would not be a real improvement over currently used work-arounds. (for details, see post on cytoscape-discuss)

I have a working implementation for local attributes (not using 'attribute namespaces') that I maintain as forked version of cytoscape 2.4. As the second part of my google summer of code project, I plan to merge this to cytoscape 3.0.

see also: thread on cytoscape-discuss where I submitted a previous patch for cytoscape 2.4 implementing local attributes

Implementation plan:

• implement backend part (about one week) (details)

• update all core code and coreplugins that use attributes due to the semantic change that local attributes mean. (about two weeks)

Flexible line types

If all goes according to plan, after implementing the above two features I will still have some time left. This will allow me to work on another feature.

As noted in Idea 6 on the list of GSoC project ideas, currently cytoscape only allows a limited set of edge types. I plan to make this part more costumizable by allowing custom Stroke instances to be used.

The aim is to replace the currently hard-coded linetypes with a more flexible approach that is easier to extend and customize.

Implementation plan:

• review current framework used for rendering, create benchmarks so that rendering speed can be measured (one week)
• make necessary changes in rendering code / API to allow more flexible line types (one week)
• handle saving / exporting such custom lines (in XGMML, for example) (one week)
• vizmapper integration: use custom lines in preview dialog (one week)

Deliverables:

For all features described above, I would create patches (with unittests, where appropriate) for cytoscape 3.0, so that these features can be seamlessly integrated into core cytoscape part of the upcomming 3.0 release.

Timeline

• first week (starting on May 26th): setting up svn account and svn branches, eclipse, build enviroment
• second and third week: undirected edges (as noted above in implementation plan)
• fourth to sixth week: local attributes (as noted above in implementation plan)
• sixth to tenth week: flexible line types (as noted above in implementation plan)

From Jun. 23th to Jun. 27th I will be attending the NetSci 2008 conference. so I won't be able to work on cytoscape during this week.

About myself:

I am currently a graduate student in Tamas Vicsek's group, working on complex networks. My homepage is at http://angel.elte.hu/~abeld/ where my academic CV and my publication list are available.

As part of my research-related work, I have adapted cytoscape for our uses. This included creating some plugins, but also fixing some bugs and adding some features to core cytoscape code. Because some of these additions involved changes to large parts of cytoscape, with the possibilities of introducing further bugs (especially for use-cases which are different from ours), most of these changes were not yet merged upstream, into the public cytoscape. During my summer of code project, I would like to clean-up these features, and integrate them into the public cytoscape codebase.

I have contributed to the cytoscape wiki (using the username DanielAbel, see list of my contributions) and reported >20 bugs (using the username 'Abel Daniel', see list of bugs reported by me) in the cytoscape bugtracker, and offered suggested fixes, patches to several of these.

Using the abli@freemail.hu email, I have been an active participant on cytoscape-discuss.

On a more general note, I have been an active contributor to open-source projects:

contributing bug-reports to various projects, from debian (list of bugs) to gtk/pygtk (list of bugs)

and being an active participant on mailling lists, for example on python tutor (list of threads) and elsewhere.

I have experience programming in java, python, c/c++ and using version-control systems like subversion.