[tidal-users] thoughts on the future of TIDAL

[Steven J. <ste...@ie...>]

The architecture of TIDAL applications is essentially a general-purpose 
scripting language engine with data acquisition capability and some 
built-in constructs that relate to respiratory physiology.

When I first conceived of TIDAL in the mid-1980s, the idea of scripting 
languages was well-established in the Unix world, but the existing 
languages were not particularly powerful programming environments. It 
was the right decision at the time to create a new language and embed 
the necessary application specifics into it.

The overwhelming majority of the code in TIDAL is utterly 
general-purpose; it neither has nor needs any knowledge of respiratory 
physiological applications. Most of my plans for future enhancements are 
similarly generic: graphical interfaces, multithreading, etc.

In 2003, several powerful scripting languages exist, offering object 
orientation, multithreading, graphics, extension mechanisms, etc. Among 
such languages are Perl, Python, Ruby, and Tcl. It is certainly possible 
in principle to implement all of TIDAL in any of these languages, with 
the possible exception of the real-time device driver interface. 
Extensions and tools exist, however, to simplify wrapping the Comedilib 
interfaces into scripting languages. One example is SWIG.

Because these scripting languages are object-oriented, it would be 
straightforward to implement the fundamental TIDAL data types (channel, 
phase, and scalar, as well as other internal concepts such as sample and 
frame). I would estimate that the roughly 10,000 lines of C in TIDAL 
could be rewritten, with substantially more functionality, in 1000 lines 
of Python or Ruby.

Re-implementing TIDAL in a scripting language would mean the end of EDL. 
The features of EDL (and much more) would be implemented in objects, and 
the user's program would simply make direct use of them in the scripting 
language. The big advantage is that the user would not have to learn a 
special-purpose language. There are many books and other resources 
available to anyone wanting to learn Perl, Python, or Ruby.

At this point, I'm just mulling some ideas over. The idea of rewriting 
TIDAL in Python or Ruby is very intriguing. (I don't really care for 
Perl syntax.) Ruby, for example, has bindings for GTK+ and Tk, which 
would simplify creation of graphical output and graphical user 
interfaces. It has native support for threads, which would greatly 
simplify programming the internal data handling. (A great deal of the 
complexity in TIDAL is due to the fact that the original MS-DOS platform 
had very poor support for multithreading in any form.)

As of May 2003, I've done some simple prototyping with Ruby and I 
believe the concept is workable.

Steve