index
The different informations about a filter will be saved as a file on the server. Why do we not simply send the file ? The same file could be used for the client cache.
After intensive reflexions (sic) and analogy with HTTP, it appears that there are two parts in the services that will be provided by the server.
The server doesn't need to conserv something in memory about the client that uses the service.
We will use the same ideas used on the web : trying to disconnect from the server as quickly as possible that means short services.
A filter will use memory and CPU, maybe a long time, there are also intensive interractions between the client and the server. We may not want to offer this service to everybody : login and password. Long time : we need to use a different thread for applying the filter, so the filter may answer to the stateless service answers from any other clients. (TODO - Corba and threads ??)
Assembling all this ideas ... IDL 2nd version
Some optimization will be to create conventions about the RessourcePath of our objects so the client may build hisself such path. : IDL 3rd version
The files should be comprehensives, we will use XML.
Here are some propositions
of content of some files (XML or PNG), and their associated RessourcePath:
Lioubliou is the part that handles with communication with clients. Lioubovnik provides the functions for calling and interpreting a filter on a document.
After analyse, it seems that a good way to make things working well together will be that Lioubliou is an instance of Lioubovnik. The constructor of the Lioubliou needs to provide 2 functions :
run method that
calls the run method of the Lioubliou which
calls the run method of the ORB.
It has been found out that two "vendors" may use the same Lioubovnik but offer different filters. We may so simply pass in the constructor of the Lioubovnik in which directory it can find the filters.
The Lioubovnik will chroot in this directory.
A simple implementation
of the getRessource server method
will be :
RessourcePath
Since we may want, (for a clean modularity) to have the code of the filters in the same directory that its description ; there will be certainly other files in the directory where we found the description that only the description of a filter and it's screenshot.
Therefore we prefix all the files that can be
getRessource-d.
The prefix is prefixed with Tbl.
We may check the prefix before
sending : more security (don't want to send the code of the filter).
In the future we may want to enable dynamic interfaces, that means we will use interface xml stream that has been not read from a file, but created during the run-time of the server.
For that getRessource may
use a semi virtual filesystem : if the RessourcePath starts
with /DynamicInterfaces/, ask
the object that handles with dynamic interfaces to provide
the xml stream passing the RessourcePath ; else use the
default implementation.
If Jentchina needs a ressource from a particular server, it will first look if it has it in the cache. Jentchina may organise its cache by user, by application, and by server.
The .Jentchina directory in the home directory of each user will look like :
.Jentchina/
|-- Abiword
| |-- ibm
| | |-- Authors
| | |-- Server
| | |-- Export
| | | |-- Latex
| | | `-- HTML
| | | |-- Smally
| | | `-- QModel
| | `-- Interfaces
| `-- siemens
| |-- Authors
| |-- Import
| |-- Export
| | `-- HTML
| |-- Server
| `-- Interfaces
`-- OOffice
|-- corel
| |-- Authors
| |-- Export
| | |-- PostScript
| | |-- RTF
| | `-- HTML
| |-- Server
| `-- Interfaces
`-- redhat
|-- Authors
|-- Server
|-- Export
| |-- PostScript
| `-- HTML
`-- Interfaces
The constructor of Jentchina needs an identifier of the client (e.g. "OOffice").
When we detect that the server is on the same machine that Jentchina,
we can symboly link the directory getRessource-able
in the cache :
ln -s /usr/share/AbiwordSiemensTblServerFiltersDirectory ~/.Jentchina/Abiword/Siemens
