[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

mcp 2 on lambdacore; strategy



prompted by networker's remarks, i've spent some time tonight seeing
how hard it is to install the MCP 2 dispatcher on a recent LambdaCore
database.  the answer:  it is not easy.

some of the members of this mailing list may not know that LabSpace
(the project that ken, dave and i worked on at northeastern university
before working for at&t) provided an implementation of what we
referred to as MCP 2.  the details of that implementation are slightly
behind the current spec, but it is certainly close enough to serve as
a reference implementation with a little hacking.  (i'm speaking only
of the server-side implementation, here; we also provided a
client-side implementation, but it's written in a variant of Scheme
and it's probably not the right thing for a reference implementation.)

the mcp 2 dispatcher is provided in a "module" format, a format that
describes a set of objects, verbs, and properties.  LabSpace also
provided an implementation of tools to install and generate these
modules.

at any rate, after an hour and a half of work i have a version of the
module system that installs on lambdacore, and a version of the mcp
module that can almost be installed by it.  (those who have tried to
install the mcp module know it doesn't completely install even on
jhcore.)  i have not tested to see if the modified mcp module works.

i could provide the two modified files in their current state, but
that's not really the right thing.  the downloadable version of the
module system has a few bugs; the mcp 2 implementation isn't in line
with the current spec.  when this code is changed, new versions of the
files will be made; the right thing is for this process to generate
JHCore and LambdaCore versions, rather than just generating the jhcore
version and requiring someone to do this hour and a half of work
again.

which brings up some interesting questions: who's going to provide
reference implementations (client and server) of MCP 2?  who's going
to maintain the module system that it's transported with?  (i disagree
with networker's desire to do away with the module layer, btw.)  in
order for MCP to be in widespread use (see Networker's post), all of
this stuff needs to be stable and supported, as well as reasonably
easy to install.

anyone?

--erik

p.s.  labspace's code is available at
  <ftp://ftp.ccs.neu.edu/pub/research/labspace>
.  module.jhm.gz is a script suitable for @pasting into a jhcore-based
moo; mcp.jhm.gz is a module suitable for installation via the module
system.  documentation for this installation process is one of those
things that a reference implementation needs to supply.