Framerowk for Project/Session management proposal(draft).

Introduction:

Problematic of the IPC distibuted app framework approach:

The Unix environment has allways characterized itself for it's high amount of versatility. This is done by following a philosophy based on ``make small apps, and make them interoperate as much as possible''. Unix has so far achieved this interoperation through pipes and very versatile command line environments. Nowadays, the new APIs found in recent apps also gear for this. A good example is the audio area, where transport APIs such JACK or ALSAseq proovide great interoperatibility between applications. This way, the user is able to do, with many programs interconnected through IPC means, the same as it's done on other plataforms (such as Windows/Mac) with big monolithic programs with follow the host-app approach. The IPC approach gives users and programmers more freedom when writing applications, since it doesnt expect a certain program to run on a specific framework ,host app or library, and frees the ``controller'' programs from tasks such as routing, control and interconnection. However this approach as it is now has a problem; it often becomes hard or almost impossible to keep ``projects'' organized, or as something heterogeneous. Every app saves it's own file format or project files, and many dont even support saving, since they are run from commandline. It is clear that becomes impossible to store a ``project'' in a single file, either a reference or description of what was worked on, or even a simple compressed file containing all the data from the applications, details of api routing, etc which could be zipped and archived for later work, sent to a friend, or just ready for usage in another workstation.

Proposed solution:

This proposal aims to proovide a way to organize the multiple applications managed by the user when working on a project. In other words the aim is to create a workspace where the user can launch as many ``client'' applications as needed from a ``server'' application, which will be able to store and retrieve the configuration of any ``client'' application at the user will. This framework will also be able to save current layout state of all ``clients'' running (including the ones in charge of interconnection) into single project file. Basically the usre will be able to ``suspend'' and ``restore'' sessions at anytime, and in different locations as if it was a simple program status file. The creation of this api also encourages further usage of IPC frameworks by prooviding an easy way of managing complex application interconnection layouts.

Implementation Overview:

The implementation of such system would involve the creation of the following modules:

Application server.
Application server interface
Client library

Implementation:

Application server:

The application server is the program in charge of launching and talking to the applictions. The natural steps for it's usage are the following:

Configure an application entry: This mean defining the file to execute, the parameters and a priority. The priority affects the order in which programs are launched when opening an existing project (ie: server apps first, client apps second and routing apps last). Also for the interface, defining an icon (xpm?) can be useful.
Launching the application: When the user needs an application, it will launch it from the server. There are several reasons why this has to be done this way, instead of launching an application first and register it to the project later.
Configure the applications: If a project was loaded, applications need to be configured, the server will send to the applications the information they need. (This information is supposed to have been previously sent to the server on a previous save). Notice that not all applications need to be use this method. Many applications (and specially the command-line based ones) are configured by passing a command-line parameter at start, and their status wont change over time. For these, the server only needs to save which parameters were passed. An example of such kind of application would be jackd, timidity, or iiwusynth.
Trace the work: While the user works on a project, the application server mantains a log of applications being loaded/quit. It may eventually have autosave features.
Save the work: When the user decies it's time to stop working on the project, it tells the application manager to save the layout. The following basic options should be proovided:
1. Soft status save: The server will ask the user to save the files individually for each project (if they werent saved, or if they were just loaded.. most apps already keep track of the current working files), then the applications will tell the server which files were being worked on. Applications can decide wether doing this or, (if due to the simplicity of the application, it doesnt save status because not much data is used) send the current status to the server for adding into the project file (a simple special format -xml compatible?- will be proovided for apps to write a status layout).
2. Project save: The server will ask all the applications to save to a certain directory (and with a specific name?) instead of just performing a normal save, so at least the base project can be contained in a single dir (or file if ziped).
3. Hard save: This is like a project save, but it includes _all_ the data used, even if it takes large amounts of megabytes of data. Samplers/disk recorders may be asked to save all their tracks/patchsets in use to the project directory. This is good for project backups. Also, for commandline programs which are not state-managed, the server proovides the user with a list of files which are going to be used.
Quit: At quit time, the server can deinitialize/quit all the applications in order (inverse priority order) to avoid the user to have to close them one by one.

Client library:

Applications which are going to be state-managed need will be proovided of a library. This library is intended for reducing the programmer's work to a minimum of just polling commands from the server and calling the respective functions for sending/retrieving data. One thing to be noticed is that the server will need to pass the application (at launch time) information about its name and where to connect to the server (this way multiple projects can be opened), this information will be simply passed through special command line options, which will be grabbed by the library at runtime (api_init), and then argc/argv will be modified as if these parameters didnt exist.

API Function Reference:

Api init/finish:

These are called when loading/quiting the app.

Function: Description:

void api_init(int *argc, char *argv[]); Session init, call in your main() function _before_ anything else

void api_finish(); Call at exit.

Function:	Description:
void api_init(int argc, char argv[]);	Session init, call in your main() function _before_ anything else
void api_finish();	Call at exit.

Session Management:

These take care of communicating with the server.

Function: Description:

int api_get_current_session(api_session_t session); Get session object instance - return 0 on success 0 on error

int api_get_event(api_session_t session,api_event_t event); Get an event, return 0 on succes 0 on certain error conditions - commands are treated later

int api_get_pending_event_count(api_session_t session); Returns the pending events count, if 0, no events are pending.

int api_get_configuration_data(api_session_t session, api_config_t config); Get configuration data, return 0 on succes 0 on certain error conditions - how to create/read cnfigs is treated later

int api_send_configuration_data(api_session_t session, api_config_t config); Send configuration data to server, return 0 on certain error conditions - how to create/read configs is treated later

char * api_get_working_project_directory(api_session_t); Ask the api for the working directory to where saving files, NULL

EEvent:

Function:	Description:
int api_get_current_session(api_session_t *session);	Get session object instance - return 0 on success 0 on error
int api_get_event(api_session_t session,api_event_t event);	Get an event, return 0 on succes 0 on certain error conditions - commands are treated later
int api_get_pending_event_count(api_session_t *session);	Returns the pending events count, if 0, no events are pending.
int api_get_configuration_data(api_session_t session, api_config_t config);	Get configuration data, return 0 on succes 0 on certain error conditions - how to create/read cnfigs is treated later
int api_send_configuration_data(api_session_t session, api_config_t config);	Send configuration data to server, return 0 on certain error conditions - how to create/read configs is treated later
char * api_get_working_project_directory(api_session_t);	Ask the api for the working directory to where saving files, NULL

One can get info about the event with this function, for example, the event type may be something like ``load project'',``save small'', ``save medium'', ``save big'', ``server requests, quit'', etc. I think it has to be better defined what exactly goes here.

Function: Description:

api_event_type_t api_get_event_type(api_event_t *event); Get event type, so far should return events for loading,saving data (location/project/all), quit and alive check notifications

Function:	Description:
api_event_type_t api_get_event_type(api_event_t *event);	Get event type, so far should return events for loading,saving data (location/project/all), quit and alive check notifications

Config:

I think the config_t should be treated like something xmlish, using some xml lib. Is this the best way?

About this document ...

Framerowk for Project/Session management proposal(draft).

This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.48)

The command line arguments were:
latex2html -split 0 api.tex

The translation was initiated by Juan Rojo on 2002-07-23

Juan Rojo 2002-07-23