GSoC Ideas 17 & 18

[gerardo huck]

Hi Everyone!

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

[gerardo huck]

Hi all!

Any feedback/info would be greatly appreciated!

Thanks!

Gerardo

[Mike Smoot]

Hi Gerardo,

Sorry for the slow reply.  For Idea #17 I think that we've got most of the pieces in place for approach #2. However, getting from a list of tasks that have occurred to an executable script is another matter entirely, which is where I think the real challenge for this project would come from.

We'd need to update Idea #18 a bit, because a basic command processor has already been implemented (command-executor-impl).  What hasn't been implemented is a nice terminal like we had in 2.x.  We also may need a few tweaks to get better feedback to users.

Either project would be really valuable to Cytoscape.  Idea #18 would probably have more short term success, but Idea #17 is more interesting from a research perspective.

thanks,

Mike

--
You received this message because you are subscribed to the Google Groups "cytoscape-discuss" group.
To post to this group, send email to cytoscap...@googlegroups.com.
To unsubscribe from this group, send email to cytoscape-disc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cytoscape-discuss?hl=en.

--
____________________________________________________________
Michael Smoot, Ph.D.              
UCSD Department of Medicine
tel: 858-822-4756

[gerardo huck]

Hi Mike,

first of all, thanks for your reply.

Unfortunately, I haven't had enough time to research and write a
decent proposal, so I've decided not to apply this year to GSoC.

I hope that many outstanding projects will be made this year and that
many lucky students will be able to be part of this great experience.

Cheers,

Gerardo