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