Hi Edwin,

> after reading thru, seems to me that *Class is used to change class
> definitions (from wiki/er.l and doc/family.l). examining wiki/gui.l,
> seems to me that class definitions (say +Doc) are kept in top-level.

Exactly. '*Class' is simply a global variable holding the "current
class". Functions like 'dm' (define method), 'var' (define class
variable) and the database relation functions like 'rel' use it to know
where to put the definition.

So if you define a method

   (dm action> (Arg1 Arg2)
      (body) )

then it is meant that this is the method 'action>' for the class that is
currently in '*Class'.

If you want just to define a single method for a class '+MyClass', the
global variable '*Class' is not needed at all. You could also write
instead

   (dm (action> . +MyClass) (Arg1 Arg2)
      (body) )

which is equivalent to

   (extend +MyClass)

   (dm action> (Arg1 Arg2)
      (body) )

or even

   (setq *Class '+MyClass)

   (dm action> (Arg1 Arg2)
      (body) )

The difference is just the side-effect of modifying '*Class'.


In fact, 'extend' is just syntactic sugar instead of 'setq'

   : (pp 'extend)
   (de extend X
      (setq *Class (car X)) )
   -> extend


> execution flow now would look like:
> 
> a) define classes using `(extend)` or `(class)`
> b) open the db
> c) accept requests
> d) do whatever
> e) render the page
> f) goto #c

Yes


> questions:
> 
> 1) am i on the right track so far?

Yes

> 2) as far as i can tell, only 1 db can be opened at any time. how does
> one deal with multiple databases?

Correct. The currently open database is a global resource.

To operate on multiple databases, you could use 'pool' to switch between
them. 'pool' is used in the beginning (point 'b)' above), but can also
be used at later times, as it closes a possibly open database first
before opening the next one.

I have never really tested this (I think Henrik did that once), and I
expect it to be somewhat inefficient as there is quite some overhead due
to lost caches.

I would rather start separate applications, one for each database, and
define a communication protocol between them using sockets and the 'pr'
and 'rd' functions. This is well tested, and has the additional
advantage that the databases my reside on separate machines for better
scalability. Moreover, I would say the typical case is not to have
multiple databases, but a single database distributed across multiple
machines.

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to