Re: lispworks' answer to allegro cache ?

On Fri, 14 Apr 2006 01:42:02 +0000 (UTC), mac <emailmac@gmail.com> wrote:

> Franz seemed to be getting a lot of attention (and business) with
> allegro cache.
>
> I'm not sure if it is appropriate for lispworks to state their
> stance in this mailing list, but I was wondering if there is a plan
> to provide something similar to it.

You might want to visit the ECLM where Arthur Lemmens will talk about
his new "Rucksack" library:

  <http://weitz.de/eclm2006/>

Dave Fox and Martin Simmons from LispWorks will also be there.

And one seat is still available... :)

Cheers,
Edi.

Re: lispworks' answer to allegro cache ?

On 16/08/5766, at 06:42, mac wrote:

>
> Franz seemed to be getting a lot of attention (and business) with  
> allegro cache.

Does not seem so with regard to the business. Their sales are  
agressive and I think it is because the business is not so good.  
Besides, at least ACL 7.0 is buggy, and they can't fix their bugs  
(Allegro support contacted me, got a bug report and then disappeared;  
and I have two more yielding SIGILL on insane code fragments running  
on all other implementations).

I believe that it is at least partly because AllegroCache is bundled  
with ACL and not a portable product; when I make decisions about  
technologies, I avoid lock-in as much as possible. So it is good news  
(Rucksack) that a possible alternative with LispWorks is not vendor- 
bound.

David

Re: lispworks' answer to allegro cache ?

Re: lispworks' answer to allegro cache ?

On Fri, 14 Apr 2006 12:27:24 -0400, "David Young" <youngde811@gmail.com> wrote:

> I'm not sure it's something Lispworks really needs. We wrote a thin
> C/Lisp layer over Sleepycat's Berkeley DB, using it as an embedded
> database. It's fast and reliable, and didn't take long to write. We
> use it in conjuction with CL-STORE.

Apart from the fact that I'd personally prefer pure Lisp solutions for
various reasons, I think that Berkeley DB is a solution most
commercial projects will have problems with - you either have to
release your code under the GPL or you have to pay /lots/ of money.
Don't know if that'll change now that Oracle has bought them.

Cheers,
Edi.

Re: lispworks' answer to allegro cache ?

Re: lispworks' answer to allegro cache ?

> Franz seemed to be getting a lot of attention (and business) with
> allegro cache.

As others say, I'm not sure how much real business they are getting
from Allegro Cache.  It's probably a good sales tool, though.

Having said that, Allegro Cache is cool and I think it is the sort of
problem that everyone solves uniquely for their particular project.  I
wish there was a popular solution that most people used that ran on
LispWorks and others.  For me, that would be more attractive than a
LispWorks only solution.

One more datapoint on what people do in the real world: Since we have
a slightly irrational dislike for RDBMS so we wrote a simple B+Tree
implementation in pure CL -- I think it only took a few days if I
remember right.  Berkeley DB is also an attractive solution that we
considered but it had those licensing issues.

Regards,
Chris Dean

Re: lispworks' answer to allegro cache ?

Actually I would like to see something where you could save the image
in a running mp LW image.  Right now you have to start up LW is non-mp
mode and save an image.  If there could be a facility for a dynamic
save image and continue then I could could see the ability to write
a simple LW DB Server for smaller apps that need centralized controlled
persistence.

The idea behind this is that a Lisp Image is a Database.  You can store
data is all sorts of forms,code(triggers) and meaning into it.

It may also be nice to create something analogous to sys:in-static-area
where persistent objects could be allocated and then split/joined into
a Lisp Image.

An interface like

persistence:in-persitent-storage
persistence:attach-persistent-store
persistence:detach-persistent-store

Wade

mac wrote:
> Franz seemed to be getting a lot of attention (and business) with allegro cache. 
>
> I'm not sure if it is appropriate for lispworks to state their stance in this
> mailing list, but I was wondering if there is a plan to provide something
> similar to it.
>
> I know there's PLOB, but it seems that there are some licensing issues with the
> c code it uses (http://plob.sourceforge.net/). Plus it's not as easy to use as
> allegro cache.
>
> For a lot of projects with large data set, allegro cache really shine. If anyone
> feel the same and wish something similar available for lispworks, please speak
> up here so Xanalys can seriously consider the possibility...
>
> -- mac
>
>
>
>   

Re: lispworks' answer to allegro cache ?

Re: lispworks' answer to allegro cache ?

On Tue, 18 Apr 2006 12:40:03 +0100 (BST), "Tim Bradshaw" <tfb@cley.com> wrote:

> Well, of course, an enormous amount of commercial software is not
> actually distributed: for instance if you use Berkeley DB to run
> your website or ASP then you're just fine, because you don't release
> any code.  Of the remaining commercial systems, the great majority
> ship in very small numbers and are correspondingly expensive, so
> licensing costs probably are not crippling there.  For mass-market
> commercial applications (which is a small minority of them)
> licencing socts may be a big deal, but I suspect you can negotiate
> in that case.

I'm in the second category - most of the time I ship custom-made apps
in very small numbers.  I negotiated with SleepyCat in the initial
phase of one project two years ago, but each of their offers was far
beyond what would have been a reasonable price for us.  AllegroCL
including AllegroCache is dirt-cheap compared to Berkeley DB.

> I'm kind of in the opposite camp to you I guess - though I'd like a
> Lisp solution in some theoretical sense, I don't really want to
> reinvent any wheels if I can avoid it, and I'm also aware that
> Berkeley DB has had a lot of performance &c work on it which I'd
> rather not have to do.

I think this very much depends on what you're doing.  AllegroCache
itself is a good example because they initially used BerkeleyDB as a
backend, then switched to a Lisp-only solution, and found out that
they were faster that way.  If you know your data well, you'll most
likely be able to beat a general purpose B-tree implementation like
BerkeleyDB given enough effort.  (No, I haven't done this myself.)

Re: lispworks' answer to allegro cache ?

Le 20/04/2006 10:57, Edi Weitz écrivait :

>...
>I think this very much depends on what you're doing.  AllegroCache
>itself is a good example ...

That's the point. Some years ago, I have 
developped an application using Allegrostore 
(ancestor of AllegroCache, backend ObjectStore). 
Now that I have some experience with CLSQL and 
PostgreSQL, I'm sure it would have been very 
difficult to develop this application without a 
true OODB: many classes in the schema and 
permanently evolving schema while in production (weekly update during months).

I think a full Lisp solution is better because of 
the royalties and dependance problem (I remember 
a bug where Franz had to wait many months a fix from the ObjectStore company).

BTW, I like vendor-bound solutions because it usually means better support.

Francis

Re: lispworks' answer to allegro cache ?

"David Young" <youngde811@gmail.com> writes:

> I'm not sure it's something Lispworks really needs. We wrote a thin C/Lisp
> layer over Sleepycat's Berkeley DB, using it as an embedded database. It's
> fast and reliable, and didn't take long to write. We use it in conjuction with
> CL-STORE.

Well, I chose lispworks because I need to do commercial application
development, so something based on Berkeley DB would not work for me.
What we did is write a layer on top of CommonSQL, but I would have
preferred a "real" object DB for that part of the project.  I really
tried to use PLOB!, but could not get a license for POSTORE.

I agree with the initial poster that this would be a great selling
point for LW.  I don't know what this "rucksack" thing is about, but
I hope it uses something closer to LLGPL or BSD, so it's also
usable for commercial purposes.