[caplisp-devel] Greetings caplisp denizens!

[David M. <ra...@gm...>]

Well as the creator of this thing I suppose I should get the ball rolling!

I think I can skip the 'who are we?' portion of the program as the
initial members (5 of us I think!) of this list are all from
captalk/e-lang-land, as I intended it.   I'm pretty sure most of the
rest of the lisp community would think we're crazy, and we know how
nearly universally blind almost all of the wider security community is
to the theoretical shortcomings of purely ambient authority, principal
based systems.

So yeah, this is by definition a 'build it and they will come' move,
or rather a fora to build tools that I intend to use to build software
that will shake the roots of the Net.
Hey, gotta have a 'take over the world' angle in there somewhere, no?
How else is one to fire up the troops, as it were! :-)

Anyhoo, forgive me if the following runs too long, or the tone becomes
a bit too much in the style of a manifesto in parts.

Here are my initial personal priorities for capability-like features
to add to Common LIsp, keeping as much within the Standard as
possible, breaking it only if we must, keeping as much as possible
compatible with multiple CL implementations:

1. httpsy

I'm pretty much of a mind with Jed on this one, start from the Network
and go in.  Compatibility with other cap systems is a major design
goal for me, and Tyler has whipped up a very nice URI type there, and
interoperability will be required for capabilities to reach any
critical mass in the market.  I want to leverage them with as much of
the full power of lisp as I can.  I don't care what other people use,
but I want to be able to talk to them and their systems' objects, and
I hate wheel reinvention.


2.  E-style event loop concurrency with promises.

Now that I can talk to others via httpsy, I'd like to be able to do so
in a deadlock-free manner.  I've not seen anything in the (2? 3?)
years since I subscribed to e-lang/captalk that has convinced me of
any better paradigm for distributed computing, at least in most
general cases.  Lots of code can probably be salvaged or encapsulated
at a lower level from threading libraries that already exist for many
CL implementations, with suitable modifications of course!


3. Factories, and whatever recursive sub-goals that ends up including.

4. Una, I don't want my Factories to make just things that sit on a
HD, I want dynamic, Secure Objects a la Nick Szabo's paper on that
topic.  Ones that can be traded via distributed auction platforms.

I'm pretty certain all of those have quite a few subgoals that need to
be mapped, and the feature priority gets fuzzier and the subgoals
bigger as you move down the above list.

As to issues of licensing, since most of the open source capability
universe appears to me to be under a Moz. or MIT style license, as are
most of my preferred CL implementations (at least the self-hosted
ones), I started with that as the license setting for the project on
sourceforge.  That's changeable with any future release if we
need/want to, and of course multiple licenses and differently licensed
shim libraries for linking to incompatibly licensed code is always
possible (if inconvenient) if there is sufficient motivation for it.

Lisp implementation: I'm starting with sbcl as my platform for initial
feature development.  As I'm going to use cl-uffi as my foreign
library calling convention for evil things like ssl/tls that no one
wants to build from scratch, most if not all of the early work (esp.
on httpsy) should run on at least a half dozen or so Common Lisps.  Oh
and sbcl is mostly public domain, with a very few (sometimes large)
bits under MIT license, which adds motivation to the previous
licensing paragraph, too.

Cheers and thanks for signing up for the list!

Sincerely,

David Mercer
Tucson, AZ