On Wed, Jul 28, 2010 at 17:51, Mark Wilkinson <[email protected]> wrote:
> LOL! So you're saying that Taverna doesn't eat it's own dog-food? (i.e.
> read it's own XML header information)
.. some boring techie details.
The File->Open dialogue finds a list of file opening handlers from its
plugins. (Implementations of
net.sf.taverna.t2.workbench.file.DataflowPersistenceHandler) Each
handler says which file types (and thereby which extensions) it can
load or save.
The t2flow opener handles .t2flow extension and the
application/vnd.taverna.t2flow+xml mime type.
The File Open dialogue should have a Type dropdown allowing you to
filter the folder by the given extension. The All Supported type is
the union of these, but the dialogue will dispatch opening to the
matching handler, which in this case was for Taverna 1 workflows,
known by their extension of .xml or mime type of
application/vnd.taverna.scufl+xml. ( Ideally we would have liked
.scufl for Taverna 1 workflows, but we can't change what extension old
versions of Taverna produce. )
The t1 handler uses legacy libraries from Taverna 1 to parse the file,
so we can't easily dispatch based on inner XML details.
Handlers can also open from different data sources like URLs, files
and pure bytestreams.
Future file formats (like SCUFL2) might not be XML-based, for instance
SCUFL2 could be ZIP/RDF based.
There is a fallback mechanism for unknown file types, this is
currently used by File-Open-from-URL. Ideally this should dispatch by
mime-type, or even more ideally Taverna should send Accept-headers
with supported mime types. This mechanism will simply try each of the
installed handlers that can handle the source (URL) in turn, and the
first to open will win.
The problem is when the file does not open - who's handler's error
message do you display? The URL opener will show the error of the last
tried handler, which would not make sense when the first ('correct')
handler had a more meaningful error message. This was in particular a
problem for local files as *xml would match any XML file. We therefore
made the file handler always use the correct handler based on file
extension, so that a more meaningful error message could be presented.
(Note that with Taverna 2.2 there should no longer really be errors in
opening a valid workflow, as we now "force-open" workflows which
services are offline or from an unknown plugin.)
The myExperiment plugin uses the bytestream mechanism to allow opening
of private workflows, and in that case one can't rewind and try to
open again with the different handlers, so the file type is passed
around from the myXP metadata.
I'm sure we can find plenty of examples of programs who have different
behavior for different file extensions, but also many ways in which
Taverna's file opening mechanism can be improved! ;)
--
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
taverna-hackers mailing list
[email protected]
Web site: http://www.taverna.org.uk
Mailing lists: http://www.taverna.org.uk/about/contact-us/
Developers Guide: http://www.taverna.org.uk/developers/
