OpenIsis NOTE: this document describes early OpenIsis proposals. For updated information please refer to Malete By now, OpenIsis is mainly used for web publishing of Isis databases. Web developers use the Java, Perl or PHP binding for this. There also is a command line version which serves as a demonstration and test of the various features and can be used as a utility for data import/export and similar tasks. A graphical, standalone user interface similar to UNESCO's WinIsis will be developed during 2003, after the Tcl/Tk binding is finished. See current status developing OpenIsis In general, there are no plans to reimplement every piece of code ever written for isis. To be of practical value, OpenIsis has to maintain compatibility in the format of the database files anyway. So, one may use winisis or whatever existing import scripts to create and maintain the database, yet deploy OpenIsis' perl interface to run powerful reports and the Java Native Interface to allow queries from a Servlet based web application. OpenIsis will focus on providing tools rather than applications. For example, there will be no attempt to mirror the full functionality of winisis. To achieve this, OpenIsis provides access from the most important programming languages: Java and PHP for the web, Perl for the scripts and Tcl/Tk for platform independent GUIs (partly DONE). All others can, of course, link the lib. Roadmap for the development of OpenIsis -- as of September 2002 After more than a year of OpenIsis development, experimenting with various options and environments and some feedback, we learned something about what is important to the community and what is not. findings and goals A fairly portable C library that can be plugged into Java, Perl, PHP or Tcl proved to be valuable and estimated by several developers. There was not much demand for a pure Java version. There is high demand for a GUI version similar to WinISIS (cross-plattform, of course) with a safe multi-user capability. This in turn requires a simple but fast and robust server. Multithreading can greatly improve the throughput. Users are used to incompatible file formats, formatting and so on. There is little of a standard to follow. So building a next generation system clearly is more important than sticking to the (which?) legacy too much. The power buried in the similarity between ISIS records and other structures like, for example, E-Mails is not leveraged. The existing versions of the formatting language are the result of a process of growth, adding feature after feature. The logic is mixed with the presentation (e.g. HTML literals). conclusions The multiformat support will be dropped in favour of an efficient support of the "DOS/WinISIS" (packed little endian) structures. The database kernel has to support basic thread-safety for use in Java and other server environments. Tcl will be the scripting language of choice: Tcl/Tk for portable GUIs and a limited set of Tcl commands for server side scripting. flavours The core library will not contain any particular external technology, so it is as lightweight as possible and can be linked into Java, Perl, PHP, Tcl and the like. There are binaries in plain, with Tcl and with Tcl/Tk. Any of these can act standalone, as client, as server, or both. volunteers are welcome !

ToDo For the current status please refer to Malete underway ... finish Tcl binding create Tk-based GUI utilities for nested records XML I/O-conversion utilities next steps (not necessarily in that order) update language bindings Perl, Java ... rework formatting based on structured representation of format as a record rework query processing based on structured representation of query implement new metadata implement views implement unicode collation