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) ;-) Cheers, - Alex -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
