[cells-devel] Re: [cells-gtk-devel] Re: Anything new for me to show off at ECLM 2008?

[Ken Tilton]

Andy Chambers wrote:
>> OK, don't make yourself crazy on my account. In fact, I already have
>>Cells-gtk as I had it last running on my laptop, I might just leave it at
>>that. I am going to try to get to Celtk, Cello, TripleCells (lite
>>integration with an RDF triple-store), Cells-Gtk, and OpenAIR (the
>>cells/ajax bit andy is doing). Whew!
> 
> 
> Will they be recording this stuff?  

We'll be trying. :)

> I've seen you mention the
> TripleCells stuff before and am intrigued.  Is it basically automatic
> serialization of cells instances?  That would be the best database
> ever! 

Scary right? The database -- it's alive!!! I actually did that on the 
trial management project, which was different because that itself was 
persistent CLOS. RDF is just this lower-level deal, but as such could 
readily adapt to being a persistent CLOS-alike. But on the CTM project 
we had Franz's full-blown persistent CLOS implementation dancing to the 
Cells:

   a persistent slot could depend on other persistent slots of the same 
or other persistent instances.

   s dynamic slot of a persistent instance could depend on persistent or 
non-persistent slots.

   dynamic instances could depend on persistent or dynamic slots of 
persistent instances

And then I added a couple of things, one of which was depending on the 
/population/ of a peristent class, kind of like depending on a dynamic 
kids slot.

Then we added a little IPC so one process could scan in a new document 
and then another process showing a GUI list widget of documents would 
suddenly show a new one -- no "refresh view" required.

Only took a couple of weeks, IIRC, in part because Franz did a nice job 
on their metaclass and Cells at the time was metaclass based.

> You could define a lispy report language that had access to a
> directory full of cells families.

Sure. You could do something like have the report itself be a DB object 
and have it automatically updated when its inputs changed, with suitable 
laziness so it does not regenerate itself on every I/O. A lot of times 
one gets batches of reports that require a common view of the DB and 
shops write extraction programs to generate a pre-digested breakdown off 
which several reports can run.

And it is a great way to get tons of business logic into the database. 
Our favorite trick was to scan in two pages of a three page form. 
2dbarcodes linked a page back to the DB form (we generated documents 
from the DB as well as scanned and ICRed them) so we knew how many pages 
to expect. The code to scan just wrote out what it found, but the Cells 
logic said "there is a missing page error" on this form simply with a 
rule that looked like:

   (cond
     ((< <pages-scanned> <pages-printed>)
      (make-instance 'user-error
         ....

etc etc where user-error was a persistent class. Slot-values linked it 
to the form in question, so anyone opening the application immediately 
saw a hot list of problems. It was trivial then to add code to show them 
the form with the problem and the scan history related to that form, and 
because of our audit trail we could also tell them which user had done 
the scanning on which machine. Made for great demo. :)

So far the RDF version is just very light proof of concept, I do not 
really need it, just thought it would be fun to do and only took a 
couple of days.

Back to OpenAIR...

kt