> First of all, I would like to (re)introduce myself. My name is Gerardo
> and I'm a Computer Science student from Argentina. I took part in GSoC
> the last 3 years, all of them working in different parts of Cytoscape
> (so far I've created 2 plugins and introduced changes in the core
> plugins of the 2.8 release, in order to allow automatic node labels
> positioning).

> I'm really interested in working again with this great community and
> software, so I'm writing this mail to discuss my ideas and request
> some more comments while I prepare my application. Also, I still need
> to decide between these 2 options: ideas 17 and 18.

> Please, find below my commentaries/questions about each one of them.

> --- IDEA 17: Add Data/Computation Provenance Support to Cytoscape 3.0
> I completely agree on the importance of being able to create
> reproducible data, specially within the scientific community, in which
> any research/experiment is supposed to be reproduced by third parties
> for verification. Bringing this capability to Cytoscape would be a
> very useful addition.

> Cytoscape 2.x has the ability of storing "sessions", although I am not
> very sure what kind of analysis it can store besides the networks,
> network views, layouts, etc. What kind of information cannot be
> actually stored in Cytoscape 3 sessions? Is it meant to include more
> "state" than Cytoscape 2.x?

> Regardless of what kind of information is required to be captured in
> this "state", I can think of two different approaches for dealing with
> this (both are also summarized on the idea description as two stages
> of the same process, but I believe that they are completely separate
> way of solving this issue.

> Approach 1: Capture the state of the session. This can be done in many
> ways: from storing the complete execution stack (of the program in the
> Java VM) to create a persistent copy of the objects involved. Any
> suggestion based on the current Cytoscape 3 architecture?

> Approach 2: Use a command pattern, or a similar concept, in order to
> be able to reproduce the steps that would take a new session to the
> current state of the program. This may be a problem, since there are
> "commands" that are non-deterministic (e.g. many layouts), so the
> actual results from that action would need to be stored.
> After an initial implementation, many possible optimizations are
> possible; for instance, if some nodes where layed out several times
> only the last position needs to be tracked, if some action was
> cancelled by another then it can be ignored, if the results of some
> analysis were closed then it can be skipped as well.
> If this approach is used, it would be very useful to have already
> implemented a command processor, so that the reconstruction of the
> current state can be written as a script to be interpreted by it.

> --- IDEA 18: Implement a Command processor in 3.0
> I believe that this may be another really useful addition to
> Cytoscape, since CyCommand is probably one of the most used features
> in Cytoscape 2.x.

> The idea description says that there's a prototype already built, but
> has no pointer to it. Is it possible to get access to it so that I can
> try/study it?

> Also, is there any documentation about tunables and tasks as they
> appear in Cytoscape 3? Otherwise, a pointer to the actual code would
> suffice as well. I have already checked out and compiled the code, and
> I'm skimming though it trying to understand it, but I have to say that
> it is pretty impressive (and different from the 2.x version which I'm
> slightly familiar with).

> I would really appreciate any commentaries/feedback/critics/etc. I'm
> pretty sure I'm missing lots of pieces and any kind of help will be
> very helpful.

> Thanks in advance!

> Gerardo Huck