...and to follow up my last mail, some things the platform doesn't do (for now!) or does wrong. Most of these issues aren't actually to do with the platform itself, and are related to the enactor, workflow model and politics, but that doesn't stop them being annoying!
* Performance of the reference service isn't great. That's mostly because the person who wrote it (me) doesn't really do databases and it's based on hibernate. Actually it's not that bad, but it would be easy to improve it (write a JDBC based DAO, or implement an in-memory burst cache using spring aspects). * Logging and reporting of platform activity could be a lot better. It's currently very hard to produce a UI component to show what the platform's doing in terms of downloading files etc. This would require a patch into the DownloadManager code. * No overall generic UI to PluginManager, although this wouldn't be too complex to implement. * No class sharing between plug-in packages, this means you can't actually write a reference translater properly as you can't get at the various reference implementations. This isn't an immediate concern, but it's a future irritation. To fix this needs some classloader voodoo in the plug-in manager itself. One option would be to fail over to all other plug-in class loaders in the event of a load failure in the local one, which would inherently export everything but would prioritise locally defined versions of classes within a plug-in package. I suspect that's the way to go rather than an OSGI-like export directive in the plug-in description. * No full docs for the plug-in description editor, although people seemed to get on fine with it at the workshop based on the exercise notes so I don't think this is entirely critical. * Reference system doesn't pick up per-workflow-instance thread pools, that should just be a question of cascading the logic to detect the pool through into the reference translater (not that anything's currently using it AFAIK). * Edits and workflow edit kit do not provide full coverage of the workflow model, so it's not currently possible to write a full workflow editor. This is a general (non platform-specific) issue with the current code and needs to be sorted out before we start trying to build proper editing interfaces. * There are no well defined APIs for the user interface part of Taverna. * Serialize / deserialize relies on XStream, which in turn uses private fields and not bean set / get methods. The platform docs 'lie' in a sense as they tell you to write beans for configuration objects etc. This is a well intentioned lie though, you should be using beans and the serializer should as well! XStream really isn't appropriate for this kind of use, but changing it will, by definition, change the XML format to one incompatible with the current version. I'm not actually bothered by this as I regard all current T2 code as beta (so don't rely on it not changing!) but I'm aware this isn't a general perception. Short term pain for long term sanity, or leave it to bite everyone horribly in the future? * Serialize / deserialize logic currently binds plug-in versions into the XML. This isn't a problem now, but in the future we'll need a mechanism to upgrade the plug-in used by a particular workflow definition. This is the same issue as the workbench currently has with artifacts, just with plug-in identifiers instead. * Pause / resume / other operations will not fail cleanly if you attempt to do something daft like unpause a workflow that's already finished. These should probably throw an IllegalStateException under those conditions. The code required to fix this is in the DataflowImpl where it tracks the dataflow instance state for all instances of that dataflow, there's a method to fetch or create a state - this should take a boolean to specify whether creation makes sense or whether it should throw an exception in those cases. * No provenance API, and the hooks needed to do it properly aren't fully there (someone would need to implement the layer conversation listener design, but that's non-trivial). Anyone trying to do this will need to take a long look at the layer state management in DispatchStackImpl. * No timetable for integration with the myGrid version of the Taverna workbench. This means you can write plug-ins for the platform, or you can write plug-ins for the workbench but they're different (slightly different APIs, different packaging and deployment). The original intention was to have this integration done by now but re-scheduling at Manchester has meant this didn't happen. * Finally, there are no projects on the planet that couldn't use more test cases (except possibly SQLite - http://www.sqlite.org/testing.html). The platform is not an exception. Tom ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ taverna-hackers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/taverna-hackers Developers Guide: http://www.mygrid.org.uk/usermanual1.7/dev_guide.html FAQ: http://www.mygrid.org.uk/wiki/Mygrid/TavernaFaq
