ANN: Descot, Decentralized Scheme Code Tracker -- Library Repository
Aaron W. Hsu
lack of a central library repository for Scheme systems should look
like. PLT has PlaneT and Chicken has their eggs, but these are both
repositories meant for only one implementation.
I argued that Scheme needed a repository that would aggregate code
together without stepping on the toes of corresponding implementations.
That is, I argued that a repository would have to be minimally
invasive while still being useful in order for it to gain widespread
adoption in the community.
I have been working on just that.
Descot is a Decentralized Scheme Code Tracker. It is decentralized
because at its core is an RDF Vocabulary describing libraries, and
a server which will (very soon) mirror other servers which operate
using this same vocabulary. Interfacing between servers is a matter
of personal taste, with HTTP a simple good start.
On top of this, I have decided to implement a web client first,
since this seems to be all the rage these days. This will permit
an user to search for libraries in the repositories mirrored by
Descot, as well as browse them and submit new libraries to the
repository. Soon I'll be supporting the decentralized part of
the whole thing by allowing people to submit new repositories for
inclusion in the index.
Currently, I am submitting this out to the public because its still
not complete. I want to get feedback from everyone on how they
would want the system to work, since, afterall, this won't work
if people aren't will to use it.
What I would like to see by the end of the Summer is both the
Chicken and PLT repositories mirroed using Descot protocols by
the main Descot Server, along with the Chez Libs library.
For those interested, please see the Descot Web Page at
<http://descot.sacrideo.us>
But please not that it's still Alpha quality software and is
rather unstable.
For those who wish to poke around at the code, please see the CVS
repository:
CVSROOT=ano...@anoncvs.sacrideo.us:/cvs
CVS_RSH=ssh
$ cvs -q -d $CVSROOT co descot
It is anonymous, so there is no password required.
Thanks, and feel free to submit some libraries and start testing
the system!
--
Aaron W. Hsu <arc...@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++
Marc Feeley
> Some of you may recall my comments about what a good solution to the
> lack of a central library repository for Scheme systems should look
> like. PLT has PlaneT and Chicken has their eggs, but these are both
> repositories meant for only one implementation.
>
> I argued that Scheme needed a repository that would aggregate code
> together without stepping on the toes of corresponding implementations.
> That is, I argued that a repository would have to be minimally
> invasive while still being useful in order for it to gain widespread
> adoption in the community.
>
> I have been working on just that.
Have you considered contributing to Snow (http://
snow.iro.umontreal.ca/)? It has much of the same objectives as
Descot, and it already supports 15 Scheme implementations. I admit
that the Snow project has been dormant for a while, but if you (and
others) were to contribute it could evolve and see more widespread
use.
Marc
leppie
> Thanks, and feel free to submit some libraries and start testing
> the system!
Typo:
This libray is distributed using CVS.
vmag...@gmail.com
Can you give a few typical Descot use cases for library users,
library authors, maintainers of other servers, etc?
What about package-management tools like chicken-setup?
Am I correct to assume (I haven't read the code yet) that since
you'll be mirroring RDFs, an implementation-specific server
would be able to store some additional information in them,
so that it's package manager could use Descot to locate libs?
What is the (planned) external interface for such tools?
Is there a spec for what's in your RDFs?
> This [a web client] will permit an user to search for
> libraries in the repositories mirrored by Descot,
> as well as browse them and submit new libraries
> to the repository.
What about downloading?
The example lib says "This libray is distributed using CVS".
Is a uniform way of downloading (from web, command-line, etc) planned?
How are author/maintainer/implementation names mapped to links?
The web interface for submitting libraries does not seem to have
this functionality.
The link to RDF file of the example lib [1] gives a file
with size 0. I guess the correct URL would be [2].
I assume your code is in Chez, and it uses Chez FFI for sockets,
so no luck for Petite?
[1] http://descot.sacrideo.us/rdf/libs/system/malloc#chez
[2] http://descot.sacrideo.us/rdf/libs/system/malloc%23chez
Aaron W. Hsu
>On Apr 23, 12:14=A0am, Aaron W. Hsu <arcf...@sacrideo.us> wrote:
>> Some of you may recall my comments about what a good solution to the
>> lack of a central library repository for Scheme systems should look
>> like. =A0PLT has PlaneT and Chicken has their eggs, but these are both
>> repositories meant for only one implementation. =A0
>>
>> I argued that Scheme needed a repository that would aggregate code
>> together without stepping on the toes of corresponding implementations.
>> That is, I argued that a repository would have to be minimally
>> invasive while still being useful in order for it to gain widespread
>> adoption in the community.
>>
>> I have been working on just that. =A0
>Have you considered contributing to Snow (http://
>snow.iro.umontreal.ca/)? It has much of the same objectives as
>Descot, and it already supports 15 Scheme implementations. I admit
>that the Snow project has been dormant for a while, but if you (and
>others) were to contribute it could evolve and see more widespread
>use.
I considered Snow as a possible solution to the Scheme Library
Distribution problem, and I came to the conclusion that it fails
in a number of key points which make it socially and technically
intractible in the Scheme world we live in today.
Firstly, it requires a framework to be built on top of one's existing
code in order to use it. In other words, it does not make pristine
libraries available to the user of a given implementation without
also forcing a shift in the structure and layout of their code tree.
For example, I can't just download a library from Snow and drop it
right into my lib directory of dependencies and then start using it
with
(include "lib/some_lib.ss")
in my files. It *requires* the additional usage of tools and other
such things. I don't think this is a good restriction to make.
So far, from browsing the Snow framework, I couldn't find any good
examples that allow Snow to give me libraries just the way I wanted
them, in the format that I wanted them. In other words, Snow
enforces too much structure on the distribution of libraries.
Secondly, Snow doesn't make it easy to make your own libraries available
to the rest of the world in a common format that can be hosted
from anywhere. Decentralized repositories are important. Right now,
people maintain their own set of repositories in one location, and
having to submit new package descriptions to a central place just
makes life harder for them. If instead, simple scripts were available
for them to distribute their repositories of code the same way they
do now, but with one or two extra files in there trees, and the system
would automatically grab them an incorporate them in, this would
make things easier and they would be more likely to use the system.
Thirdly, the fact that your system requires implementations to
do something special to support it makes it less appealing. With
Descot, you can collect a web of libraries and information without
ever worrying about the details of implementations being supported by
the system or not.
In future phases of the system, I would like to incorporate Snow
like package systems that allow one to use Descot databases like
they would Snow, but this is a sub-problem. I would also like
to consider the automatic translation of libraries into native
code for implementations that were different than the original
implementation used to submit the code, but this is a ways down the
road.
Actually, Descot solves a different problem than Snow. Snow is a
tool for getting and installing libraries, but it is one that can
co-exist with Descot. If Snow were amended to utilize the Descot
format(s), then Descot would mirror its repository, and make it
available alongside things like Chicken Eggs and PlaneT code.
Then, Snow tools could also be used to install Descot Libraries,
and there would be yet another way to manage your libraries, but
it would be in a way that was compatible with many other potential
distribution methods, and thus, wouldn't lock someone into using
one way or another.
Thus, I don't think Snow is the right way to go as a total solution
to library distribution in Scheme. It is one direction of many that
ought to be able to cooperate together. Descot seeks to provide the
glue that will allow things like Eggs, PlaneT, Snow, and regular
old Tarballs of code, &c. work together, without stepping on too many
toes.
Descot is still in its infancy, and it will need plenty of help to
get it to the point where it can be truly successful, and that is
why I need help from people like you, who maintain repositories
already.
In Summary, Descot's Goals are:
1) Provide a means of aggregating repositories and libraries
together.
2) Permit the decentralized hosting of library metadata in a
portable, understandable way.
3) Make it possible to access these libraries in many different
ways, without enforcing a single means of access.
4) Make it possible to use libraries with minimal disruption
of workflow in any implementation. That is, without enforcing
one specific module system, retrieval method, or layout.
Marc Feeley
I understand your point. However, it should be easy to extend Snow to
support other kinds of package formats. That's what I meant when I
said that you (and others) could help make Snow evolve into a more
"acceptable" system. I'm not trying to push the current Snow package
structure, which I know has problems. My goal is to offer a package
distribution system that users of many different implementations of
Scheme can use. Snow has lots of *portable* infrastructure for
package distribution and it would be a pity to start a new system from
scratch.
Marc
Ray Blaak
> For those who wish to poke around at the code, please see the CVS
> repository:
>
> CVSROOT=ano...@anoncvs.sacrideo.us:/cvs
> CVS_RSH=ssh
>
> $ cvs -q -d $CVSROOT co descot
Is this a repository for the downloadable libraries as well?
I strongly recommend the use of SVN over CVS. SVN plays much nicer as a
public shared repository than CVS does. It's ability to detect arbitrary
file changes including renames and deletions makes the management and
review of general user changes much more robust.
Really, SVN is an advancement of the state of the art for centralized
repositories.
Now, that said, given the goal is for decentralized repositories, you
probably want to look at Git, which is all about decentralized source control.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYb...@STRIPCAPStelus.net The Rhythm has my soul.
Grant Rettke
> I have been working on just that.
A unified description and repository format for distributing Scheme
code would be great; it would serve everyone who wants code be it via
direct downloads (or local repos) or their implementations package
management software.
Aaron you should write up a paper on this to make it more clear as to
what exactly is your vision and goals.
While you already do have your ode to "A repository should not be
designed by...", you will need more than that to draw people in :).
namekuseijin
> Marc Feeley <fee...@IRO.UMontreal.ca> writes:
>> Have you considered contributing to Snow (http://
>> snow.iro.umontreal.ca/)? It has much of the same objectives as
>
> code in order to use it.
Same issue with SLIB as well...
BTW, nice initiative.
The main issue so far with Scheme libs has been a lack of standardized
module system. It meant inevitable name clashes if one was to simply
drop in a lib via load or include. Either this, or play by the
framework rules. Then each Scheme implementation decided implementing
its own module system and this mostly means non-portable libs. Then
came R6RS with a standardized module system proposal and was derided by
most implementors because they already had several non-portable libs in
their specific module systems.
I wonder how Descot will cope with that, though it feels it's more like
an indexer for existing disparate Scheme libs than an approach to
standardize libs in any given module system.
--
a game sig: http://tinyurl.com/d3rxz9
William D Clinger
> Aaron you should write up a paper on this to make it more
> clear as to what exactly is your vision and goals.
+1. And maybe submit it to the Scheme workshop.
namekuseijin wrote:
> I wonder how Descot will cope with that, though it feels
> it's more like an indexer for existing disparate Scheme
> libs than an approach to standardize libs in any given
> module system.
There would be a lot of value in having that indexer,
precisely because it could cope with existing disparate
libraries and languages. Neutrality is also a virtue,
as it can replace some of the political pressures that
surround standardization with a market solution based
on availability of competing resources.
For example, it doesn't sound as though Descot will be
limited to any particular framework or library system,
and will be neutral with respect to IEEE/ANSI/R5RS versus
R6RS versus other standards and proprietary anti-standards.
Will
Aaron W. Hsu
>Can you give a few typical Descot use cases for library users,
>library authors, maintainers of other servers, etc?
Library Users:
At the moment, you bide your time as you wait for your
libraries to get into the system, or prod people to put
them into the system. Since Descot is still very new, it's
not quite completely useable, though it is getting closer
every day.
After I have the infrastructure setup, you would just use
your preferred client, whether web, CLI, or in code, to
grab the libraries from the servers. You would also search
for libraries using the Sparql server or the client's built
in support.
Library Authors:
You would have two options, though right now, you only have
one. One would be to submit your library's data to the main
Descot server or another repository. The other would be to
host your own repository (which will be trivially easy) to
track your source, and then submit the mirroring URL to the
servers, where they would be mirrored.
Maintainers of other servers:
You would normally do very little, except maybe quality control
on the content of your server and the like. In fact, being a
maintainer of a server really isn't any different than being
a library author, except that you wouldn't be writing the
libraries that you are hosting.
Currently, there is only the web interface with a simplistic web
form for submission. This needs to change, and it will. I am considering
the use of Snow as a CLI based framework for grabbing and searching
the libraries. At any rate, I will be improving the web version
significantly to make adding libraries easier and more robust.
>What about package-management tools like chicken-setup?
I anticipate making some of these, but in large part, you are not going
to be forced into one package management system at all. In fact, you
could continue to use Chicken's package management if you so wanted,
it would just so happen that their system would be linked in with
Descot, so you might see Chicken Eggs in the Descot index.
>Am I correct to assume (I haven't read the code yet) that since
>you'll be mirroring RDFs, an implementation-specific server
>would be able to store some additional information in them,
>so that it's package manager could use Descot to locate libs?
This is one of the intended extensions. A Location node in the
RDF Vocabulary allows systems to provide information to the packaging
systems and other clients to provide download information. Right now
there are built in generic types for single files, archives, and
source control mechanisms, but the only sophisticated download node
type that is built in at the moment is CVS. Others, such as Chicken
or PlaneT location pieces could be trivially added.
>What is the (planned) external interface for such tools?
I hope that people will make whatever interface suits them the most,
at least, I would like to see Web, CLI, Gopher, GUI, and in-code
interfaces to the repository. All of them would be utilizing Descot
Servers with Descot languages and protocols.
>Is there a spec for what's in your RDFs?
It has been available in CVS, but a version is now available through
the web at <http://descot.sacrideo.us/10-rdf-schema>.
>> This [a web client] will permit an user to search for
>> libraries in the repositories mirrored by Descot,
>> as well as browse them and submit new libraries
>> to the repository.
>What about downloading?
Download information is presented to the browser. Right now, only
CVS, Direct File, and Archives are supported, but more are easy to
add and a server can support libraries with additional download
information without necessarily having any knowledge of that new
form.
>The example lib says "This libray is distributed using CVS".
>Is a uniform way of downloading (from web, command-line, etc) planned?
There is no uniform way of getting Scheme libraries, and so no
standard is planned. I don't want to force a framework of distribution
on anyone. In other words, no, you'll get the libraries however
they were intended to be obtained. Certain clients such as those
based on Snow could very easily give a "one stop shop" method of
getting the libraries and installing them. However, I want all
different ways of getting the libraries and installing them to be
available, because Schemers all like their flavor.
>How are author/maintainer/implementation names mapped to links?
>The web interface for submitting libraries does not seem to have
>this functionality.
At the moment, I am doing these semi-manually. A more sophisticated
interface is planned once I have more time to work on it.
The intention is that an implementation/author/maintainer has a node
for themselves that other libraries all point to. This could be
self hosted by the user or could be hosted for them on a server. I
don't deal with duplicates at the moment, and I don't think it will
cause a problem, yet.
>The link to RDF file of the example lib [1] gives a file
>with size 0. I guess the correct URL would be [2].
Yes, sorry about that. That's a bug. It is fixed now.
>I assume your code is in Chez, and it uses Chez FFI for sockets,
>so no luck for Petite?
Hehe, of course you can use it with Petite. The only thing is that you
would need to have the modules that require the sockets library to
be compiled for you. One of the things I intend to do is provide binaries
for Descot and for the Chez Libs in general, which means that you could
use Petite to run the system.
If you are interested, I can get you something, but at the moment, I
don't know that the server is ready for that level of public consumption.
:-)
Aaron W. Hsu
>I understand your point. However, it should be easy to extend Snow to
>support other kinds of package formats. That's what I meant when I
>said that you (and others) could help make Snow evolve into a more
>"acceptable" system. I'm not trying to push the current Snow package
>structure, which I know has problems. My goal is to offer a package
>distribution system that users of many different implementations of
>Scheme can use. Snow has lots of *portable* infrastructure for
>package distribution and it would be a pity to start a new system from
>scratch.
Yes, I am all in support of Snow supporting Descot, and from what I
saw, I think it could be a very decent CLI interface to Descot. I
think that would be nice, especially, since I don't really have the
time to do all parts, and I certainly want to leverage the existing
work of people like you.
Descot isn't meant to get in the way, but I hope that Snow can adapt
to utilize the benefits of Descot.
Aaron W. Hsu
>Aaron W. Hsu <arc...@sacrideo.us> writes:
>> For those who wish to poke around at the code, please see the CVS
>> repository:
>>
>> CVSROOT=ano...@anoncvs.sacrideo.us:/cvs
>> CVS_RSH=ssh
>>
>> $ cvs -q -d $CVSROOT co descot
>Is this a repository for the downloadable libraries as well?
Descot does not enforce any central or even per repository download
format or method. Instead, Descot is concerned only with Library
Metadata, and in that data is stored the means to obtain the library
from what ever means the library authors wish to use. This means that
the libraries could be available through PlaneT, Direct Download,
or even SVN, CVS, Darcs, &c. It is even conceivable to have
commercial libraries documented through this system, since the format
allows the author to specify any format that he would like to use.
This above is merely the AnonCVS repository for the Descot Code itself,
which is not a library right now, and is actually a full blown program.
>I strongly recommend the use of SVN over CVS.
I use CVS. :-) Descot doesn't make you use it. :-D
Vitaly Magerya
Can you give a few typical Descot use cases for library users,
library authors, maintainers of other servers, etc?
What about package-management tools like chicken-setup?
Am I correct to assume (I haven't read the code yet) that since
you'll be mirroring RDFs, an implementation-specific server
would be able to store some additional information in them,
so that it's package manager could use Descot to locate libs?
What is the (planned) external interface for such tools?
Is there a spec for what's in your RDFs?
> This [a web client] will permit
> an user to search for libraries in the repositories mirrored by
> Descot, as well as browse them and submit new libraries to the
> repository.
What about downloading?
The example lib says "This libray is distributed using CVS".
Is a uniform way of downloading (from web, command-line, etc) planned?
How are author/maintainer/implementation names mapped to links?
The web interface for submitting libraries does not seem to have
this functionality.
The link to RDF file of the example lib [1] gives a file
with size 0. I guess the correct URL would be [2].
I assume your code is in Chez, and it uses Chez FFI for sockets,
so no luck for Petite?
[1] http://descot.sacrideo.us/rdf/libs/system/malloc#chez
[2] http://descot.sacrideo.us/rdf/libs/system/malloc%23chez
Abdulaziz Ghuloum
> Grant Rettke wrote:
>> Aaron you should write up a paper on this to make it more
>> clear as to what exactly is your vision and goals.
>
> +1. And maybe submit it to the Scheme workshop.
I second this. There doesn't seem to be much information
at the site at the moment, but hopefully, Aaron has it
all figured out and it's a matter of putting it on paper
(deadline is coming soon).
> namekuseijin wrote:
>> I wonder how Descot will cope with that, though it feels
>> it's more like an indexer for existing disparate Scheme
>> libs than an approach to standardize libs in any given
>> module system.
>
> There would be a lot of value in having that indexer,
> precisely because it could cope with existing disparate
> libraries and languages. Neutrality is also a virtue,
> as it can replace some of the political pressures that
> surround standardization with a market solution based
> on availability of competing resources.
>
> For example, it doesn't sound as though Descot will be
> limited to any particular framework or library system,
> and will be neutral with respect to IEEE/ANSI/R5RS versus
> R6RS versus other standards and proprietary anti-standards.
I agree with all of this too. Actually, I did not start any
such repository effort for R6RS libraries not for lack of
interest but precisely because of all the reasons mentioned
above. So, Aaron, best of luck executing your ideas.
Aziz,,,
Aaron W. Hsu
>On Apr 22, 11:14=A0pm, Aaron W. Hsu <arcf...@sacrideo.us> wrote:
>> I have been working on just that. =A0
>A unified description and repository format for distributing Scheme
>code would be great; it would serve everyone who wants code be it via
>direct downloads (or local repos) or their implementations package
>management software.
>Aaron you should write up a paper on this to make it more clear as to
>what exactly is your vision and goals.
I am currently planning a paper right now. I'll be giving a localized
talk on the project tomorrow, but I hope to have something to distribute
in the coming months.
>While you already do have your ode to "A repository should not be
>designed by...", you will need more than that to draw people in :).
Of course, but, I'll let the work speak for itself in a large respect,
and probably talk a great deal about it to boot. I plan a LOT more
information on the Descot page that details the technical aspects of
the system as well as all the formatting and details as soon as I
have the time for it. The first stage was just to get something
semi-working so people could start using it a little.
Aaron W. Hsu
>Aaron W. Hsu escreveu:
>> Marc Feeley <fee...@IRO.UMontreal.ca> writes:
>>> Have you considered contributing to Snow (http://
>>> snow.iro.umontreal.ca/)? It has much of the same objectives as
>>
>> Firstly, it requires a framework to be built on top of one's existing
>> code in order to use it.
>Same issue with SLIB as well...
Yes, when I compile the entire documentation and rationale for Descot,
I'll discuss that issue. Of course, Descot doesn't interfere with
the likes of SLIB.
>BTW, nice initiative.
Thanks.
>The main issue so far with Scheme libs has been a lack of standardized
>module system. It meant inevitable name clashes if one was to simply
>drop in a lib via load or include. Either this, or play by the
>framework rules. Then each Scheme implementation decided implementing
>its own module system and this mostly means non-portable libs. Then
>came R6RS with a standardized module system proposal and was derided by
>most implementors because they already had several non-portable libs in
>their specific module systems.
Descot is my proposed solution to the Scheme Chaos. I contend that such
Chaos really isn't a bad thing in this state of the art, since we
really don't have good or de facto standards on which to work that
are universally or mostly universally enjoyed. Rather, we should be
finding a way to cooperate within the world that we live, which is largely
chaotic. We shouldn't try to change it, but by cooperating more easily,
it just might change.
Descot, instead, will cooperate with all module systems and Scheme
implementations, and just might eventually get some work done on
automatic porting between them.
>I wonder how Descot will cope with that, though it feels it's more like
>an indexer for existing disparate Scheme libs than an approach to
>standardize libs in any given module system.
Attempts to standards library modules and formats have mostly failed to
achieve the holy grail. I'm not going to try to do the same thing.
Rather, I thin it's more important to know what is out there first,
and then maybe look at making it easier to get at what you want with
what you want (your chosen implementation).
Aaron W. Hsu
>Grant Rettke wrote:
>> Aaron you should write up a paper on this to make it more
>> clear as to what exactly is your vision and goals.
>+1. And maybe submit it to the Scheme workshop.
I do plan to do this.
>There would be a lot of value in having that indexer,
>precisely because it could cope with existing disparate
>libraries and languages. Neutrality is also a virtue,
>as it can replace some of the political pressures that
>surround standardization with a market solution based
>on availability of competing resources.
Exactly.
>For example, it doesn't sound as though Descot will be
>limited to any particular framework or library system,
>and will be neutral with respect to IEEE/ANSI/R5RS versus
>R6RS versus other standards and proprietary anti-standards.
Exactly.
lapla...@gmail.com
> Ray Blaak <rAYbl...@STRIPCAPStelus.net> writes:
>
> >Is this a repository for the downloadable libraries as well?
>
> Descot does not enforce any central or even per repository download
> format or method. Instead, Descot is concerned only with Library
> Metadata, and in that data is stored the means to obtain the library
> from what ever means the library authors wish to use. This means that
> the libraries could be available through PlaneT, Direct Download,
> or even SVN, CVS, Darcs, &c. It is even conceivable to have
> commercial libraries documented through this system, since the format
> allows the author to specify any format that he would like to use.
Ah. It might be useful to clearly state that on your About page. As it
stands, I'm not sure what Descot actually is. From discussion here, it
sounds like it's a central repository of xml metadata files describing
scheme source code distributions available for various scheme
implementations. If that's the case, saying so on the About page would
be informative.
Aaron W. Hsu
>I second this. There doesn't seem to be much information
>at the site at the moment, but hopefully, Aaron has it
>all figured out and it's a matter of putting it on paper
>(deadline is coming soon).
Oh yeah, I've got it *all* figured out. </sarcasm>
More information will be coming along shortly.
>I agree with all of this too. Actually, I did not start any
>such repository effort for R6RS libraries not for lack of
>interest but precisely because of all the reasons mentioned
>above. So, Aaron, best of luck executing your ideas.
Thanks for the well wishes, but I also should mention that I can't
do it all myself, and I am relying on the community stepping in and
making Descot their own. :-)
Grant Rettke
> you'll be mirroring RDFs, an implementation-specific server
You should mirror the content, too.
Grant Rettke
> Descot, instead, will cooperate with all module systems and Scheme
> implementations, and just might eventually get some work done on
> automatic porting between them.
Setting achievable goals is a *good thing*.
Aaron W. Hsu
>On Apr 23, 6:32=A0pm, Aaron W. Hsu <arcf...@sacrideo.us> wrote:
>> Ray Blaak <rAYbl...@STRIPCAPStelus.net> writes:
>>
>> >Is this a repository for the downloadable libraries as well?
>>
>> Descot does not enforce any central or even per repository download
>> format or method. =A0Instead, Descot is concerned only with Library
>> Metadata, and in that data is stored the means to obtain the library
>> from what ever means the library authors wish to use. =A0This means that
>> the libraries could be available through PlaneT, Direct Download,
>> or even SVN, CVS, Darcs, &c. It is even conceivable to have
>> commercial libraries documented through this system, since the format
>> allows the author to specify any format that he would like to use.
>Ah. It might be useful to clearly state that on your About page. As it
>stands, I'm not sure what Descot actually is. From discussion here, it
>sounds like it's a central repository of xml metadata files describing
>scheme source code distributions available for various scheme
>implementations. If that's the case, saying so on the About page would
>be informative.
Yes, the web site is still low on information at the moment. Much of
the data is stored in the code and in the Schema. However, Descot is
most certainly *not* centralized. While I would like to have a de facto
centralized location that mirrors most of the other locations, I don't
want to make Descot exist on only one server. Rather, I hope that
others will host their own repositories of their own code, or maybe
just their one library that they have written. I will be making it
easy for someone to do so, and that way, it's not really about any
one location, but allows for anyone to work with this format however
they wish.
Aaron W. Hsu
>On Apr 23, 8:41=A0am, Vitaly Magerya <vmage...@gmail.com> wrote:
>> you'll be mirroring RDFs, an implementation-specific server
>You should mirror the content, too.
I'm not prepared to mirror content just yet, but if other servers
want to do it, fine by me. :-)
Aaron W. Hsu
Yes, and I think that's the lesson to be learned in the Scheme world.
Trying to force a confederacy of independents to conform to a one
world order isn't exactly doing things the easy way. ;-)
Abdulaziz Ghuloum
> ...
> For those who wish to poke around at the code, please see the CVS
> repository:
>
> CVSROOT=ano...@anoncvs.sacrideo.us:/cvs
> CVS_RSH=ssh
>
> $ cvs -q -d $CVSROOT co descot
It would be nice if every module's page included a command for how
to obtain the code. For example, the malloc module should say:
command: CVS_RSH=ssh CVSROOT=ano...@anoncvs.sacrideo.us:/cvs cvs co
lib/malloc.ss
allowing people to copy and paste the command to get to the code.
Support for other revision control systems (svn, bzr, git, mercurial,
whatever) would be nice too.
Aziz,,,
Vitaly Magerya
>> What is the (planned) external interface for such tools?
>
> I hope that people will make whatever interface suits them the most,
> at least, I would like to see Web, CLI, Gopher, GUI, and in-code
> interfaces to the repository. All of them would be utilizing Descot
> Servers with Descot languages and protocols.
server, post a query, and receive machine-readable results?
Is it available now?
It seems that your choice of RDF as main format is dictated by
the existence of SPARQL (otherwise you've just used something
based on s-expressions), so will processing SPARQL queries
be implemented, or will there be a lighter interface?
> There is no uniform way of getting Scheme libraries, and so no
> standard is planned. I don't want to force a framework of distribution
> on anyone. In other words, no, you'll get the libraries however
> they were intended to be obtained.
Does it make sense for a web interface to provide automation
of downloading libraries available via known ways, e.g. anonymous CVS?
It could point to a service that will download the CVS, tar it,
and return link to the tarball, for example.
>> I assume your code is in Chez, and it uses Chez FFI for sockets,
>> so no luck for Petite?
>
> Hehe, of course you can use it with Petite. The only thing is that you
> would need to have the modules that require the sockets library to
> be compiled for you. One of the things I intend to do is provide binaries
> for Descot and for the Chez Libs in general, which means that you could
> use Petite to run the system.
>
> If you are interested, I can get you something, but at the moment, I
> don't know that the server is ready for that level of public consumption.
> :-)
No rush right now; we'll see what happens next.
Aaron W. Hsu
>It would be nice if every module's page included a command for how
>to obtain the code. For example, the malloc module should say:
>command: CVS_RSH=ssh CVSROOT=ano...@anoncvs.sacrideo.us:/cvs cvs co
>lib/malloc.ss
>allowing people to copy and paste the command to get to the code.
Yes, this would be nice, it is on the TODO list.
>Support for other revision control systems (svn, bzr, git, mercurial,
>whatever) would be nice too.
Yep, I'd like to get that in sometime.
Aaron W. Hsu
>OK, so what is the (intended) protocol for a tool to connect to Descot
>server, post a query, and receive machine-readable results?
>Is it available now?
The access to specific resources is currently implemented for
the main Descot server (just access the URLs and you get the RDF
sentences with that URL as a subject), but updating and mirroring nodes
aren't implemented yet. Eventually, if you just want to get a library,
then accessing its URL will be enough. If you want to query for
things, then there will be a query server available for searching.
>It seems that your choice of RDF as main format is dictated by
>the existence of SPARQL (otherwise you've just used something
>based on s-expressions), so will processing SPARQL queries
>be implemented, or will there be a lighter interface?
An S-expression format is planned. There is already some code out
there in Scheme for querying Sparql, so I'll probably use that for
clients. In part, one of the reasons I chose RDF is because it has
marketing clout outside of the Scheme community, and people know
how to use it. Much of the design was based around what could be
socially appealling and functional both in and out of the Scheme
community with the intention of bringing in people who previously
avoided using Scheme because of the library-shock factor.
>Does it make sense for a web interface to provide automation
>of downloading libraries available via known ways, e.g. anonymous CVS?
>It could point to a service that will download the CVS, tar it,
>and return link to the tarball, for example.
That's something to think about. It might be something to implement,
and it would be kind of neat to see it in action, but I would want to
spend some more time thinking about it.
>No rush right now; we'll see what happens next.
Yep!
aschemer
As the author of LambdaBeans (an IDE for Scheme that supports
different Scheme implementations) I thought I could add my 2 cents on
this important issue.
I would like to integrate a library system with LambdaBeans, so that
you can browse, search, install an use different libraries from within
the IDE, for any of the Scheme implementations that LambdaBeans
currently supports (which will be slowly *growing*).
My first take would be of course, to integrate with the Scheme Now!
effort. As soon as Descot is read I'd like to integrate LambdaBeans
with that too.
To be able to do that it would be great if those two library
repositories could have some minimum features. I thought it could be
helpful to list them below, just in case you find them of interest.
There we go:
- To be able to browse and search packages from within the IDE, it
would be great if we had a list of existing packages in a computer-
readable format. RDF would be fine, Scheme would be perfect.
- It would be great to have a mechanism to download and install/
configure those libraries. Command-line specific tools would be fine
(if those support all platforms that LambdaBeans supports, including
Windows). Scheme tools would be perfect.
- It would be great if all libraries in there could have some metadata
(author/version/etc.) in a well-known format. Again XML/RDF would be
fine, and Scheme would be perfect.
Finally it would be great if you could create and test libraries from
within LambdaBeans. And then you could package and upload those to a
repository (from within the IDE). For this to be possible it would be
great if those repositories could have a "standard" way to upload
stuff. An HTML form with well-defined fields would be enough, I
assume.
On Apr 24, 12:37 am, Aaron W. Hsu <arcf...@sacrideo.us> wrote:
> Descot is my proposed solution to the Scheme Chaos. I contend that such
> Chaos really isn't a bad thing in this state of the art, since we
> really don't have good or de facto standards on which to work that
> are universally or mostly universally enjoyed. Rather, we should be
> finding a way to cooperate within the world that we live, which is largely
> chaotic. We shouldn't try to change it, but by cooperating more easily,
> it just might change.
>
LambdaBeans is my proposed solution, and I hope we can collaborate in
making Scheme development more productive, allowing people to use cool
Scheme libraries with the implementation of their choice, more easily.
Cheers,
Antonio
Aaron W. Hsu
>I would like to integrate a library system with LambdaBeans, so that
>you can browse, search, install an use different libraries from within
>the IDE, for any of the Scheme implementations that LambdaBeans
>currently supports (which will be slowly *growing*).
>My first take would be of course, to integrate with the Scheme Now!
>effort. As soon as Descot is read I'd like to integrate LambdaBeans
>with that too.
Descot was designed to address specifically this desire. It's a
protocol that will let you integrate a repository with your programs,
like LambdaBeans.
>To be able to do that it would be great if those two library
>repositories could have some minimum features. I thought it could be
>helpful to list them below, just in case you find them of interest.
Currently, I am considering very strongly of extending Snow to
utilize the Descot interface. This would make Snow a nice CLI tool
for accessing, installing, and managing software available in the
Descot repositories.
>- To be able to browse and search packages from within the IDE, it
>would be great if we had a list of existing packages in a computer-
>readable format. RDF would be fine, Scheme would be perfect.
An S-expression based RDF representation is planned for Descot.
>- It would be great to have a mechanism to download and install/
>configure those libraries. Command-line specific tools would be fine
>(if those support all platforms that LambdaBeans supports, including
>Windows). Scheme tools would be perfect.
I think Snow already has these features.
>- It would be great if all libraries in there could have some metadata
>(author/version/etc.) in a well-known format. Again XML/RDF would be
>fine, and Scheme would be perfect.
Descot suits this purpose.
>Finally it would be great if you could create and test libraries from
>within LambdaBeans. And then you could package and upload those to a
>repository (from within the IDE). For this to be possible it would be
>great if those repositories could have a "standard" way to upload
>stuff. An HTML form with well-defined fields would be enough, I
>assume.
The current plan for submissions to descot servers is that they
will be implementation specific, but the anticipated HTTP protocol
will allow an HTTP POST submission with a body containing the library
Descot file. This would allow programs to submit libraries
automatically.
>LambdaBeans is my proposed solution, and I hope we can collaborate in
>making Scheme development more productive, allowing people to use cool
>Scheme libraries with the implementation of their choice, more easily.
Yes, and I would very much support LambdaBeans supporting Descot
repositories.
vmag...@gmail.com
For one thing, there's libraries. But you also said that people
(authors) will also have entries in Descot. So probably will
implementations.
What about articles, books, programs (tools), and maybe some
other things I've missed -- is it meaningful to index those
within Descot, and can it be done?
Grant Rettke
This is starting to sound like a Scheme social networking site!
That might be interesting.
Aaron W. Hsu
It is meaningful to index them, but this is beyond the Scope of
Descot. Descot seeks only to work within the limited domain of
solving the libraries problem in Scheme. In fact, the same
system could also be trivially applied to other languages, but
Descot won't be the one to do it for now. Authors and implementations
come into play because they are a necessary element to describing
libraries. As are function descriptions. Anything that doesn't
relate to Libraries in this way is not planned for inclusion in
the index, since Descot would become just another Google then,
which I don't want.
Aaron W. Hsu
That might be interesting, but no, I won't be doing it, and the
official Descot system won't do it. Of course, nothing is stopping
others from extending the core Descot system into a social
networking site. ;-) I don't think it's a particularly efficient
approach, though.
George Neuner
God, I hope not! Social networking is nothing but a waste of
bandwidth ;)
>That might be interesting.
George
namekuseijin
Well, what a shame! They suspended Scheme at Twitter:
Scala OTOH is going full blast there:
;)
--
a game sig: http://tinyurl.com/d3rxz9