[armedbear-devel] integrating abcl into Protege

[Alessio Stalla]

On Thu, Mar 11, 2010 at 11:40 AM, Mark Evenson <evenson at panix.com> wrote:
>
> On Mar 10, 2010, at 9:14 PM, Alan Ruttenberg wrote:
>
>> Protege is an ontology development tool. I'm interested in using abcl
>> to develop plugins and TIm Redmond was kind enough to have a stab at
>> doing a first pass integration, but ran into trouble. I wonder if his
>> report makes rings a bell?
>
>
> Attached is an untested patch that takes a stab at fixing the problem
> of loading ABCL from an OSGi loader like that present in Protege.
> It's going to take me a bit of time to get to a place where I can
> test this, so maybe someone else with a working Protege development
> environment could at least tell me if it either works (yay!), looks
> promising (heh!), or just fails (boo!).
>
> The patch is very hackish and preliminary, as by loading from OSGi
> bundles we will no longer have the property that all arguments to
> LOAD-SYSTEM-FILE are expressible as a Pathname.  I expect that this
> means that *LOAD-TRUENAME* isn't going to work very well, but I
> don't think this is going to prevent the system from at least
> initializing.
>
> I think the right approach to minimize the abstraction perturbation
> in the system load routines is to figure out a manner to express
> an arbitrary URL that Java groks via java.net.URL as a Lisp Pathname
> (not just a "jar:" or "file:" URLs as is the current behavior).  I
> think I once read (maybe in the SBCL source?) a proposal where
> Pathname HOST was to be potentially treated as a URL.  Does anyone
> know of a Lisp that fits URLs into Pathname that we could study as
> a proposal?  If we want URLs to be fairly opaque to the rest of
> Pathname (i.e. no MERGE-PATHNAME semantics etc.), it would probably
> be pretty easy to push this into the HOST part of Pathname, which
> is currently only used for logical pathnames and UNC path support
> under Windows.  This probably means that logical pathnames couldn't
> be used to refer to arbitrary URLs, but I would have to think about
> it a bit.

I don't know how hard it is, but at this point what do you think about
having an abstract base class/interface (say, Resource) which only has
a name property and from which you can extract an input stream, and
have this class be extended by Pathname, JarURLResource,
GenericURLResource, whatever? Some operations on pathnames really do
only make sense for file pathnames, not arbitrary URLs.

>
> Supporting OSGi (and Eclipse in general) is an important goal for
> ABCL, so we (I?) will try to diligently to get quickly get support
> for loading the ABCL base system from an OSGi loader.

I agree on the importance of the goal, and I'm willing to help.

Bye,
Alessio