From: Joe Marshall
Subject: [ANN] Yet another persistent CLOS
Date: 
Message-ID: <7kbe3jlw.fsf@ccs.neu.edu>
As part of a project I've been working on I've developed a simple
persistent object store for Lisp and CLOS objects.  It implements its
own database and does not depend on any third-party back end like
ObjectStore or POSTORE.

I'm toying with the idea of `productizing' it, so if anyone would be
interested in such a thing, email me.

From: Fred Gilham
Subject: Re: [ANN] Yet another persistent CLOS
Date: 
Message-ID: <u7ptp56fdj.fsf@snapdragon.csl.sri.com>
Joe Marshall <···@ccs.neu.edu>
> As part of a project I've been working on I've developed a simple
> persistent object store for Lisp and CLOS objects.  It implements
> its own database and does not depend on any third-party back end
> like ObjectStore or POSTORE.
> 
> I'm toying with the idea of `productizing' it, so if anyone would be
> interested in such a thing, email me.

A freely available portable persistent object store would be a great
thing to have around.

By `productizing' do you mean making suitable to sell?  Or would your
intent be to package it for free distribution?

-- 
Fred Gilham ······@csl.sri.com || His word is a creative word, and
when he speaks the good exists as good.  God is neither arbitrary nor
tyrannical.  He is love, and when he expresses his will it is a will
of love.  Hence the good given by God is good for us.-- Jacques Ellul
From: Joe Marshall
Subject: Re: [ANN] Yet another persistent CLOS
Date: 
Message-ID: <8yvt23gs.fsf@ccs.neu.edu>
Fred Gilham <······@snapdragon.csl.sri.com> writes:

> Joe Marshall <···@ccs.neu.edu>
> > As part of a project I've been working on I've developed a simple
> > persistent object store for Lisp and CLOS objects.  It implements
> > its own database and does not depend on any third-party back end
> > like ObjectStore or POSTORE.
> > 
> > I'm toying with the idea of `productizing' it, so if anyone would be
> > interested in such a thing, email me.
> 
> A freely available portable persistent object store would be a great
> thing to have around.
> 
> By `productizing' do you mean making suitable to sell?  
> Or would your intent be to package it for free distribution?

I'm trying to come up with a way to pay my mortgage, so the `sell'
option was what I was toying with.  Ideally, though, I'd eventually
want to make it free for non-commercial or research uses.  I'm not
sure I can afford the time to package it for free distribution in the
immediate future, though, unless *someone* can fund it.
From: Francois-Rene Rideau
Subject: Re: [ANN] Yet another persistent CLOS
Date: 
Message-ID: <87k7fd4syc.fsf@Samaris.tunes.org>
Joe Marshall <···@ccs.neu.edu> writes:
> I'm trying to come up with a way to pay my mortgage, so the `sell'
> option was what I was toying with.  Ideally, though, I'd eventually
> want to make it free for non-commercial or research uses.  I'm not
> sure I can afford the time to package it for free distribution in the
> immediate future, though, unless *someone* can fund it.
What about a Ghostscript-like licensing, then, with a free software version
lagging one year or two behind a proprietary version, and serving as an
open software escrow to reassure customers as well as to attract users?

BTW, how does your persistent store cope with concurrency, if it does?
Is it robust wrt e.g. killed process, power failures or unsynced file
modifications?

[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
What is mind? No matter! What is matter? Never mind!
	-- Bertrand Russell's Grand Mother, In Karl Popper, The Unended Quest
From: Joe Marshall
Subject: Re: [ANN] Yet another persistent CLOS
Date: 
Message-ID: <r89lzp8r.fsf@ccs.neu.edu>
Francois-Rene Rideau <····@tunes.org> writes:

> What about a Ghostscript-like licensing, then, with a free software version
> lagging one year or two behind a proprietary version, and serving as an
> open software escrow to reassure customers as well as to attract users?

I'll look into that.

> BTW, how does your persistent store cope with concurrency, if it does?

It can handle concurrent `reads', but currently doesn't try to deal
concurrent writes.

> Is it robust wrt e.g. killed process, power failures or unsynced file
> modifications?

Yes.  (of course if the file modification isn't synced, then the
unsynced data isn't seen, but the last consistent stable view will not
be corrupt)
From: Francois-Rene Rideau
Subject: Re: [ANN] Yet another persistent CLOS
Date: 
Message-ID: <87n0k935wq.fsf@Samaris.tunes.org>
Joe Marshall <···@ccs.neu.edu> writes:
>> What about a Ghostscript-like licensing [...]
> I'll look into that.
Thanks.

>> BTW, how does your persistent store cope with concurrency, if it does?
> It can handle concurrent `reads', but currently doesn't try to deal
> concurrent writes.
Hum. Not sure what that means.
Does that mean a transaction has to acquire a global write lock
before it can commit? Or you queue transactions?

BTW, I suppose we talking about in-system concurrency;
or can multiple processes access the persistent store?

>> Is it robust wrt e.g. killed process, power failures or unsynced file
>> modifications?
> Yes.  (of course if the file modification isn't synced, then the
> unsynced data isn't seen, but the last consistent stable view will not
> be corrupt)
Of course (and you don't get an ACK before it's committed).
What about the trickier case of partially sync'ed writes?

PS: I see you're now at ccs.neu.edu - have you joined the PLT team?

[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it
	-- Richard Feynman
From: Joe Marshall
Subject: Re: [ANN] Yet another persistent CLOS
Date: 
Message-ID: <8yvt1pqo.fsf@ccs.neu.edu>
Francois-Rene Rideau <····@tunes.org> writes:

> Joe Marshall <···@ccs.neu.edu> writes:
> >> What about a Ghostscript-like licensing [...]
> > I'll look into that.
> Thanks.
> 
> >> BTW, how does your persistent store cope with concurrency, if it does?
> > It can handle concurrent `reads', but currently doesn't try to deal
> > concurrent writes.
> Hum. Not sure what that means.
> Does that mean a transaction has to acquire a global write lock
> before it can commit? Or you queue transactions?

There is no concurrency control for writes, so you could get lost
updates if you tried to do concurrent writes.

However, multiple reads are allowed.  Each read recieves a transaction
consistent view that will become more and more stale as writes proceed.

> BTW, I suppose we talking about in-system concurrency;
> or can multiple processes access the persistent store?

No, just the lisp process.

> >> Is it robust wrt e.g. killed process, power failures or unsynced file
> >> modifications?
> > Yes.  (of course if the file modification isn't synced, then the
> > unsynced data isn't seen, but the last consistent stable view will not
> > be corrupt)
> Of course (and you don't get an ACK before it's committed).

The wonders of modern OSs.

> What about the trickier case of partially sync'ed writes?

Still ok, although the partial data will be ignored.

> PS: I see you're now at ccs.neu.edu - have you joined the PLT team?

Shhhh!!!  This is comp.lang.lisp!
From: Arthur Lemmens
Subject: Re: [ANN] Yet another persistent CLOS
Date: 
Message-ID: <3E65D214.FE1A240@xs4all.nl>
Joe Marshall wrote:

> As part of a project I've been working on I've developed a simple
> persistent object store for Lisp and CLOS objects.  It implements its
> own database and does not depend on any third-party back end like
> ObjectStore or POSTORE.
> 
> I'm toying with the idea of `productizing' it, so if anyone would be
> interested in such a thing, email me.

I'm definitely interested. 

In fact, I just wrote a very simple persistent object store myself.
It's based on the premise that all data will fit in memory, so it's only
necessary to log the creation and updates of all persistent objects.
I do this by defining a metaclass for persistent objects and defining
methods on (setf slot-value-using-class), slot-makunbound-using-class
and initialize-instance. Some of the MOP stuff is Lispworks-specific
and the design and implementation are rather simplistic (the complete
source file is around 30 KB), but it's already more useful to me than
the SQL-ODBC stuff that I used before.

But I don't really have the time to develop this into something that's
more portable, more efficient and more flexible. As I wrote before in
comp.lang.lisp, I'd be willing to pay for a decent persistent object store
that works on Lispworks for Windows.

Could you describe the basic ideas behind your implementation?

Arthur Lemmens