MidWay Documentation
Prev Top Next

The Road ahead

These are the features that I've planned, and to some extent readied the code for. This is not in a prioritized order. Some of these I've already has defined API for, others not.
Mwd need to have a config file
A config file are needed for and more....
A Server manager module in mwd
Starting servers directly from the command line is really just for development. mwd should be able to start and stop servers, either from executables or shared libraries, and restart them if they crash. Mwd will have some internal servers that need to be managed in the same way, gateways and TCP/IP clients servers.
a GNOME version of mwadm
A module for Apache (Begun)
Both for doing CGI call directly  to a service, and as a http protocol provider for clients.
A TCP/IP version of the client API for http.
Language bindings for perl
I consider his to be urgent, the DBI module for Perl makes Perl possibly a very important language to write services in. (A Client only SRBP module is completed).
Language bindings for Tcl/Tk
Despite that AOL embedded a Tcl  interpreter in their http server (se articles on LinuxWorld.com they are quite good, and very relevant to MidWay), I consider Tcl/Tk to be a GUI language. I'm probably catch flames for this, but I'm going to prioritize the TCP/IP client API here. (Depend on my success with SWiG>
Language Bindings for Python
Language Bindings for PHP
The API's should be pthread safe
At least the client API. To allow servers to increase their own numbers may lead to extremly many processes. Thread are more interesting in statefull "servces" such as conversations and objects.
Implement the TCP/IP client API in Java.
I don't know about the IPC API. I haven't yet looked much at servlets, it might have a need for the server API. We'll see how servlets catches on.
Transactions support, two phase commit, XA style
Needed for sending notifications (from servers) to clients.

Prev Top Next
© 2000 Terje Eggestad