"Jules F. Grosse" wrote:
> Regarding PLOB!, what is the legal status of the system? The page
> isn't clear on the availability of the system for general use.
Heiko Kirschke, the author of PLOB, recently wrote on the PLOB mailing
list (···············@lists.sourceforge.net) that the licensing model of
POSTORE, the underlying persistence tool from St. Andrews University, is
unclear and that it "was not possible to get an official commitment from
St. Andrews University that POSTORE is published under some freeware
license model".
I'd love to use PLOB myself, but because of the licensing problems I've
never investigated it more closely.
Arthur Lemmens
Arthur Lemmens <········@xs4all.nl> writes:
> Heiko Kirschke, the author of PLOB, recently wrote on the PLOB mailing
> list (···············@lists.sourceforge.net) that the licensing model of
> POSTORE, the underlying persistence tool from St. Andrews University, is
> unclear and that it "was not possible to get an official commitment from
> St. Andrews University that POSTORE is published under some freeware
> license model".
I can add to that that I myself got in contact with U. of St Andrews,
and was unable to license the software (we were willing to pay for it).
It seemed to me that as a University, they're just not set up to deal
with this sort of request, and I think there's basically no one "in
control" of POSTORE at the moment. If one of the original authors was
around to make a statement, that would be great; if they could open
source it, that would be even greater.
Alain Picard wrote:
> I can add to that that I myself got in contact with U. of St Andrews,
> and was unable to license the software (we were willing to pay for it).
Speaking of money: I'd be happy to pay $1000 (maybe more) for a decent
persistence library with PLOB-like functionality that I could use hassle-free
with Lispworks for Windows.
I wonder if there are others who'd be willing to pay for something like this.
That could be a nice incentive for Heiko Kirschke (or somebody else) to base
PLOB on a different underlying persistence tool.
Arthur Lemmens
Arthur Lemmens <········@xs4all.nl> writes:
> Alain Picard wrote:
>
> > I can add to that that I myself got in contact with U. of St Andrews,
> > and was unable to license the software (we were willing to pay for it).
>
> Speaking of money: I'd be happy to pay $1000 (maybe more) for a decent
> persistence library with PLOB-like functionality that I could use hassle-free
> with Lispworks for Windows.
Which specific functions do you desire? I could suggest UncommonSQL,
it has an object and functional interface to relational databases and
people are presently using it on LWW I believe (just answered some
questions and applied patches from them the other day). You would not
need to pay for it. Of course, I'm well aware of the differences
between something PLOB and USQL, so it could very well be that USQL
would not fit your needs.
http:://alpha.onshored.com/lisp-software
--
Sincerely,
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
Craig Brozefsky wrote:
> I could suggest UncommonSQL, it has an object and functional interface
> to relational databases
I know about the existence of UncommonSQL, thanks. I used to use Lispworks'
SQL library until Harlequin decided a couple of years ago to charge license
fees for distributing the resulting programs. Xanalys currently doesn't charge
distribution license fees anymore, but Harlequin's move scared me so much
that I decided to switch to Paul Meurer's SQL-ODBC library, which more or less
implements the 'functional interface' part. I'm working sporadically on
implementing an object interface on top of that (based on Lispworks' design,
just like UncommonSQL). At the moment, this object interface probably has less
functionality than UncommonSQL and I don't really consider it publishable, but
it does enough to be actually useful to me.
But an object interface to SQL databases is still a far cry from what I would
expect from a persistence library that's well integrated with the Lisp system
on which it's running. I've never actually worked with such a system, so my
expectations are probably rather naive, but some of the things I'm currently
missing are:
- dynamic typing
As far as I know, all Lisp libraries that are based on relational databases
require that you specify the types of all slots in advance. This more or
less pushes me back to the static typing world that I was so glad to leave
when I moved to Lisp.
- support for all Lisp objects, not just classes with slots consisting of
either other persistent classes or a very limited range of data types like
strings, fixnums, floats and timestamps.
- transparency
Ideally, I would like to just define a few persistent variables, put
everything I want to be persistent in those variables, and be done with it.
If this turns out to have very bad performance consequences, the system
should have enough hooks to fix the performance, but this should not be
necessary until then.
I suppose that one of the good parts of relational databases is that you can
handle gigabytes of data with it, but for my kind of work that's not very
relevant. I'd be happy to settle for a system that requires that all my data
fits in RAM, as long as all changes are immediately written to some kind of
persistent store.
Sometimes I think about writing such a system myself, but in my current
situation that would be too much work with too little pay-off. If I knew
that there were a market for this kind of stuff, the pay-off part improves
and I would seriously consider writing such a thing.
Failing all that, I'll repeat what I said before: I would gladly pay USD 1000
or more for a system that does the kind of things I've described above.
Arthur Lemmens
>>>>> "al" == Arthur Lemmens <········@xs4all.nl> writes:
al> - dynamic typing
al> As far as I know, all Lisp libraries that are based on
al> relational databases require that you specify the types of all
al> slots in advance.
at least with PostgreSQL, that isn't necessarily true. The response to
a SELECT query includes sufficient information to reconstruct a
lisp-level type (modulo the limited number of supported types, as you
mentioned below). This information is available at the level of the
frontend/backend protocol, but I don't think you have access to it
when interfacing to PostgreSQL via the libpq bindings. It is used in
the pg.lisp interface, to implement automatic type coercion for results
of SELECT queries to the appropriate Common Lisp types.
<URL:http://www.chez.com/emarsden/downloads/>
(pg.lisp is much lower-level than libraries like UncommonSQL)
al> support for all Lisp objects, not just classes with slots
al> consisting of either other persistent classes or a very limited
al> range of data types like strings, fixnums, floats and
al> timestamps.
I haven't tried this, but PostgreSQL allows you to define new types.
You can provide functions for the marshalling and unmarshalling that
are loaded from a shared library.
<URL:http://developer.postgresql.org/docs/postgres/sql-createtype.html>
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Eric Marsden wrote:
> al> As far as I know, all Lisp libraries that are based on
> al> relational databases require that you specify the types of all
> al> slots in advance.
>
> at least with PostgreSQL, that isn't necessarily true. The response to
> a SELECT query includes sufficient information to reconstruct a
> lisp-level type
I have no experience with PostgreSQL and I'm not sure if I understand
you correctly, but I get the impression that you're talking about a
totally different level of interface here.
I don't even want to think about SELECT queries. The whole point of object
interfaces to relational databases is that they allow you to think in
terms of Lisp objects, not database queries. The libraries inspired by
Lispworks' object interface do this as well as they can, but I think
there's a fundamental mismatch between the relational database model and
Lisp's dynamic object oriented view. I think (but I am no expert on this)
that the right way to implement persistence of Lisp objects is by
creating and managing a persistent heap (including garbage collection,
type bits to implement dynamic typing, and so on). WOOD is an interesting
example of how this could be done, but it seems to be tightly coupled to
(some older version of?) MCL; it's probably very hard to do efficiently
without such a tight coupling, by the way.
> (modulo the limited number of supported types, as you mentioned below).
Yeah. For me that's a very big modulo.
> I haven't tried this, but PostgreSQL allows you to define new types.
> You can provide functions for the marshalling and unmarshalling that
> are loaded from a shared library.
You can do this with UncommonSQL & relatives as well. But that solves
only a small part of the problem.
Arthur Lemmens
Arthur Lemmens <········@xs4all.nl> writes:
> I don't even want to think about SELECT queries. The whole point of object
> interfaces to relational databases is that they allow you to think in
> terms of Lisp objects, not database queries.
You are correct, and PLOB! solves many of these issues quite
elegantly, [storing arbitrary lisp objects without worrying about
defining a DB schema for them] and AllegroStore probably even better
(if you're a millionaire).
And Tim Bradshaw's opinion about playing nice SQL with the rest of the
world notwithstanding, I think that a free POSTORE (or something like
it) would be a great thing. Some sort of common persistency substrate
on which multiple OO dbs could be built would be cool.
You definitely want to stay away from the way the C++ crowd does it
(Versant, anyone?). I'm thinking something a la berkeley-db (not free
for commercial usage) might be a decent starting point.
But PLOB! already exists; it's cool; if only it's persistency substrate
was free, we'd be in business; I'd certainly not be using commonsql+postgresql
if I could have gotten PLOB!.
Hello!
Alain Picard <·······················@optushome.com.au> wrote:
>[...]
>You definitely want to stay away from the way the C++ crowd does it
>(Versant, anyone?). I'm thinking something a la berkeley-db (not free
>for commercial usage) might be a decent starting point.
You might consider using db-1.85 as starting point. At that point,
it is/was still BSD-style licenced (and thus it's still included
in the free BSD derivatives).
>But PLOB! already exists; it's cool; if only it's persistency substrate
>was free, we'd be in business; I'd certainly not be using commonsql+postgresql
>if I could have gotten PLOB!.
I don't know it really, but perhaps the PLOB <-> persistence layer
interface isn't *too* complicated, so it perhaps could be worth while
to rewrite the latter?
Kind regards,
Hannah.
* Arthur Lemmens wrote:
> I wonder if there are others who'd be willing to pay for something
> like this. That could be a nice incentive for Heiko Kirschke (or
> somebody else) to base PLOB on a different underlying persistence
> tool.
I think a persistence system needs to be based on some substrate that
is a `standard' in the sense that there are multiple implementations
(which might vary a bit), so you don't get shafted when the particular
implementation you are using fails you in some way (runs out of
address space, written in intercal, bogus license, blah).
It turns out that such systems exist, and they're called SQL-based
relational databases. Yes, they are deficient as object stores, but
the situation isn't hopeless. They do have the advantage that there
are free ones, and huge ones, and so on - basing your system on an SQL
backend isn't going to cause you to be bound in to some bogus bit of
software - almost everywhere you look there are options. And, better,
using an SQL backend means you get to say that your data is accessible
to non-Lisp front-ends, so the ravening Java hordes love you. If you
use a decent SQL database, you even get interlocking between the Lisp
and non-Lisp parts of the system thrown in, how cool is that?
To my (inexpert) knowledge there is no similar standard for
object-based stores, and if there is you can bet it's oriented towards
either C++ or Java, and would have horrible issues storing CLOS
instances.
--tim
Tim Bradshaw wrote:
> I think a persistence system needs to be based on some substrate that
> is a `standard' in the sense that there are multiple implementations
> (which might vary a bit), so you don't get shafted when the particular
> implementation you are using fails you in some way (runs out of
> address space, written in intercal, bogus license, blah).
> It turns out that such systems exist, and they're called SQL-based
> relational databases. Yes, they are deficient as object stores,
At the moment I do use SQL-based databases for the reasons you mention.
But for some of my projects, the advantages I expect from a well-
integrated persistent store would be much more important than the
disadvantages of using something that's not standard and not compatible
with the rest of the world. Standards are great if they exist and are
well-designed (Common Lisp being one of the best examples of this, of
course). But for me this is not an all-or-nothing issue; I'll happily
use non-standard tools when I have confidence in their design and
longevity.
Arthur Lemmens
"Arthur Lemmens" <········@xs4all.nl> wrote in message ······················@xs4all.nl...
> Speaking of money: I'd be happy to pay $1000 (maybe more) for a decent
> persistence library with PLOB-like functionality that I could use hassle-free
> with Lispworks for Windows.
>
> I wonder if there are others who'd be willing to pay for something like this.
> That could be a nice incentive for Heiko Kirschke (or somebody else) to base
> PLOB on a different underlying persistence tool.
I agree.
Has anyone considered swapping out the POSTORE backend with another
DB like Berkley DB? Then we could have PLOB! with a better licensed
backend. I assume it is doable.
--
Wade
(format t "Email: ~A"
(map 'string
'code-char
'(119 104 117 109 101 110 105 117 64
116 101 108 117 115 46 110 101 116)))
Wade Humeniuk wrote:
> Has anyone considered swapping out the POSTORE backend with another
> DB like Berkley DB?
Heiko Kirschke said on the PLOB mailing list that he's considering doing
exactly that.
Arthur Lemmens
Arthur Lemmens <········@xs4all.nl> writes:
> Wade Humeniuk wrote:
>
> > Has anyone considered swapping out the POSTORE backend with another
> > DB like Berkley DB?
>
> Heiko Kirschke said on the PLOB mailing list that he's considering doing
> exactly that.
I'd certainly pony up some money for a PLOB with some kind of
plug-in/inherited back end driver thing.
Gregm