## page was renamed from RFCTemplate
## This template may be useful for creating new RFC's (Request for comments)
## This is a wiki comment - leave these in so that people can see them when editing the page

|| '''RFC Name''' : ... || '''Editor(s)''': ... ||

<<TableOfContents([2])>>

== About this document ==

This is an official Request for Comment (RFC) for a generic framework to support importing from diverse file types.

For details on RFCs in general, check out the [[http://www.answers.com/main/ntquery?method=4&dsid=2222&dekey=Request+for+Comments&gwp=8&curtab=2222_1&linktext=Request%20for%20Comments|Wikipedia Entry:  Request for Comments (RFCs)]]

== Status ==

##Put the date and the status.  Status can be e.g. "Not yet completely written", "Open for public comment", "Closed for public comment". 
"Open for public comment"

== How to Comment ==

To view/add comments, click on any of 'Comment' links below.  By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records.  Be sure to include today's date and your name for each comment.  Here is an example to get things started:  [[/Comment]].

'''Try to keep your comments as concrete and constructive as possible.  For example, if you find a part of the RFC makes no sense, please say so, but don't stop there.  Take the extra step and propose alternatives.'''

== Proposal ==

Cytoscape is currently able to import 3 types of files, SIF, GML, and XGMML.  These file types are hard coded throughout the system (the import action, in Cytoscape.createNetwork, etc.). There is no mechanism for easily and seamlessly integrating the import of other file types, such as SBML by a plugin.  
<<BR>>
 * Define an ImportableFileType interface.  The interface will define several methods such as: fileTypeID, fileTypeSuffix, fileTypeDescription, getReader.
 * Anything that loads files (Cytoscape, ImportGraphFileAction) will include a list of objects that each implements the interface for it's particular file type.  
 * Instead of checking to see if a filename matches a particular file type with mulitple if statements, the loading class would simply loop through it's list of file type objects and then the file type object would see if it could load the file, and do so if possible.
 * Alternatively, we could centralize this behavior in a single ImportHandler object. 
 * Plugins could seamlessly add themselves to the list of allowable file types by adding a file type object to the loading class.
<<BR>>
 * This should be easy to accomplish without breaking any of the public interface. 

== Biological Questions / Use Cases ==

I want to import files of type: (fancy new file format).

== General Notes ==

== Requirements ==

Support current file types.

== References ==
  
== Implementation Plan ==

  * [[/Implementation Plan]]

-----
== Discussion ==

 * GaryBader - Mar.14.2006 - sounds great!  When complete, it would be great to have a wiki page documenting this for plugin developers e.g. How to add new file type support to Cytoscape.  Do you think it would be better to search for the classes implementing the interface or have an interface method that registers the classes with a handler?
 * MikeSmoot - Having thought about it a bit more, I think we want an interface method that registers classes with a handler.  Here is a slighty more detailed explanation of what I'm thinking.
   * Create an {{{ImportHandler}}} class with the following methods 
     *{{{addHandler(FileTypeHandler fth)}}} which registers the handler type.
     * {{{getReader(String fileName)}}} which provides a reader based on the file type.  The file type will be decided by the {{{ImportHandler}}} checking with each {{{FileTypeHandler}}} to see which one of them can read the file.
     * {{{getFileTypeSuffixes()}}} which will return a list of suffixes that can be used in file open dialogs and the like.  Again, the collection of suffixes is created by the {{{ImportHandler}}} asking each {{{FileTypeHandler}}} to describe itself.
     * probably a few other methods like {{{getFileTypeDescriptions()}}}, etc..
   * The Cytoscape object will contain the {{{ImportHandler}}} object and will provide access to the class with a {{{getImportHandler()}}} method.
   * Plugins would call {{{Cytoscape.getImportHandler().addHandler(fth)}}} to register themselves.
   * Actions wanting to import files would call {{{Cytoscape.getImportHandler().getReader(filename)}}}
   * {{{FileTypeHandler}}} would be an interface as described above in the Proposal as {{{ImportableFileType}}}.  
   * Implementations of {{{FileTypeHandler}}} would be responsible for creating their own reader class.
   * This scheme would allow us to clean up code in {{{ImportGraphFileAction}}} and {{{Cytoscape}}} and allow for new file types to be easily added by plugin.  We might even consider moving the existing file types into (core) plugins.
 * GaryBader - Mar.16.2006 - Would there be any organization of types of types?  E.g. .sif, .gml, .psi-mi, .biopax, etc. are network types, so would there be a NetworkImportHandler extension of the ImportHandler class that could be used by a "load network" dialog box (since it would be best if the file type just got added to the drop down menu of file types recognized by the network import file selection box - it sounds like you're thinking the same thing)?  How would the actual e.g. CyNetwork object be created by the import reader?  Would the same scheme be used for export as well?  Some plugins would provide both import and export functions.