[PLOB] Re: Upcoming release 2.11

[Klaus H. <kl...@ha...>]

Heiko Kirschke <hei...@gm...> writes:

> Moin Edi,
>
> Edi Weitz schrieb:
>
>>>I have still plans to replace PLOB's underlying library POSTORE with
>>>Berkely DB, but unfortunately did not have the time to do so.
>>>    
>>>
>>It'd be great if you could replace the underlying store with something
>>else.  I wonder, however, if Berkeley DB is the right solution.
>>Again, because of licensing (or rather pricing) issues.  See my email
>>to the Elephant mailing list:
>>
>>  <http://common-lisp.net/pipermail/elephant-devel/2005-March/000121.html>
>>  
>>
> Ok, reading this means that the Berkeley DB license is not suitable
> for Plob. Sigh.
>
>>Could you describe in a few words which features have to be supported
>>by an alternative back-end?
>>
> The requirements are not that high.
>
> First, I know of a successor of POSTORE called `Lumberjack' with the
> same API. Unfortunately, it looks as if the work on Lumberjack has
> stuck a bit, since the author(s) told me that it is not yet ready for
> putting it into the public domain. I will ask them again.
>
> Second, to me it looks as if  Plob should use its own underlying
> persistent heap. There are several options to this:
>
> 1. Abonding the mixed C-/LISP-approach of Plob, coding the persistent
> heap in LISP. Would mean a major redesign and cost a lot of effort.
>
> 2. Replace the POSTORE lib by an own implementation of a persistent
> heap, again in C. Would mean only a redesign on Plob's lower levels,
> with maybe moderate efforts. I cannot estimate what it would mean to
> replace the POSTORE lib by something coded in LISP, but I'm afraid
> that this would mean that I've to drop the idea of using Plob randomly
> in server or serverless mode and to decide on supporting only exactly
> one of these modes.
>
> For option 2., the POSTORE API is not that complicated. There are
> functions for allocating a persistent record with a quite simple
> structure (references to other persistent  records and values [i.e.,
> no references]), access functions to these records by their `object
> id', and some administrative functions like flushing, creating a new
> persistent heap etc. You find the interface in the SH_* functions
> declared in plob-2.10/src/include/postore.h. All other
> databasespecific stuff (transactions, btrees etc.) has been
> implemented in Plob anyway in the layer above the persistent heap.
>
> Since my time for working on Plob is rather constrained, I would
> prefer option 2.
>
> Viele Grüße from Hamburg, too,
> Heiko
>
> Heiko Kirschke
> Achtern Barg 48
> D-22885 Barsbüttel
> Tel.: +49 40 225497
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Hi Heiko --

First of all, I think this is really good news.  I tried out PLOB!
about a year ago - worked really well.  However, due to the licensing
issues and its -- apparent, it now turns out! -- status as semi-dead,
I abandoned exploration beyond the initial try-out.  It would be great
to see PLOB! revived.

I agree with Edi wrt. the licensing issues from Sleepycat - I think it
is a showstopper; it is for me/us, at least.  Even if you can use it
for private and open source projects, not being able to use it
professionally means that it becomes really hard to justify dealing
with the learning curve.

I haven't looked much at PLOB! source, but perhaps an SQLite backend
is a possibility? 

regards,

-Klaus.