(Following up from the previous note, "Re: Transpose")

How about this for a REBOL community open-source project?

    REBster: a (distributed?) "dictionary" to a distributed collection
             of servers offering a library of re-usable functions and
    objects.  The client could search the directory by: author, title,
    REBOL "flavor" (/Core, /View, /Command, etc.), REBOL release
    level (/Core/2.3, /Command/1.0, etc.), keywords, server, (did I
    leave out any obviously useful search options?)

    To maximize convenience of use, the client should use a standard
    design for a local cache of REBster content that integrates
    seamlessly with an "include" facility to make utilizing library
    parts as simple as possible.

    Such a design (possibly similar to that of CPAN) should support
    caching locally only what one actually wants to use, should
    support simple local maintenance (as in the REBOL "upgrade",
    allowing one to say "get me the most recent version of all
    the stuff I'm caching locally"), should support resolution of
    dependencies (as in the RPM "install this module and anything
    that it needs that I don't already have" mechanism).

    To provide aid and comfort to the widest possible audience of
    REBOLutionaries, this system should run on REBOL/Core (although
    individual items offered via the system could, of course, be
    designed for specific flavors).

    To be as widely accessible (and quick to build...) as possible,
    I suggest that it only utilize HTTP, as that is most likely to
    be passable through firewalls, etc.

Details of submission protocols would have to be worked out, but
there are some slightly-at-odds goals here: make it easy enough to
submit content that it's not a burden on the submitter, but insist
on having enough (documentation, meta-data, conformance to library
conventions/standards, etc.) that the recipient can easily find
what is being sought, have reasonable confidence that (s)he will
get the desired capabilities, that it won't break her/his system,
etc.

It also needs to support allowing multiple people to offer varying
implementations for a given concept with minimal red tape AND
minimal likelihood of confusion/collision.

Thoughts, suggestions, comments welcome!

-jn-

Reply via email to