Hi Tomas,

> In what cases and how you do it?

At SmApper we had a set of stand-alone shell tools (i.e. with the first
line containing '#!bin/picolisp') that were used to do quick scans of
some databases and build reports. They simply loaded the "er.l" of those
applications, and called 'pool' on the db files. As they did a single
pass over the data and then terminated, there was no cache problem, and
they did not write anything to the databases. But recently these tools
were abandoned and replaced by new versions, which properly connect to
the applications and issue queries.

> families): an admin part (quite complex, can change a lot and
> significantly, can stop quite "often" for upgrades etc.) and public
> part (quite simple, changes little, minimize downtime).

We have been using similar architectures. Our (now obsolete) 7fach
system consisted of an admin application, and a separate application for
each customer (we found only around 25 pilot customers and stopped the
project). The SmApper system also has an application manager, and tens
to hundreds of interconnected database applications on blade clusters.

It depends a lot on the logical structure, and what exchange of
information has to take place, but I think PicoLisp has the necessary
mechanisms, mainly using TC/P connections.

> - open the database 'pool'

I would use a separate 'pool' for each logical application.

> - fork into two apps (each forked process would load code for
> different app)

Yes, but you have to keep in mind that it works only well if the
processes accessing the db are children of a single parent (see 'tell'
in the reference). In this case it would mean that the two forked apps
should not do any further forks, which could be inconvenient.

If you want to go with a single parent but different sources, it is no
problem though, just load the sources after the fork. I do this
currently for one customer who is still using the old Java applet API,
and the new 'form' API in parallel (depending on the user). This app has
in fact three entry URLs, one for the AWT version, one for the Swing
version, and the new one.

Another disadvantage of having all applications using the same pool is
that you cannot put them on separate machines.

> What is '*Ext', I cannot find anything about that?

The global '*Ext', in cooperation with RPC functions and the 'ext'
function, allows to send pilog queries or other requests to remote
machines, have external symbols sent back from these machines, and
operate on these external symbols just as if they would reside on the
local database. These objects are read-only, though.

> > This whole matter is a good candidate for the Wiki ;-)
> Yes, why not, I have to understand it first though.  Or, feel free to
> put your thoughts in there;-)

Right. Posting to the Wiki is on my todo-list, but I absolutely did not
find the time yet (all spare time goes to pico3 currently) ;-)

- Alex

Reply via email to