On Fri, Jun 19, 2009 at 5:04 PM, Abdulaziz Ghuloum<[email protected]> wrote: > > On Jun 19, 2009, at 10:25 PM, Grant Rettke wrote: > >> It seems like duplication of effort if DESCOT already has the manifest >> problem solved. > > You mean the stuff in http://descot.sacrideo.us/10-rdf-schema ? > > Fine. We can use that information as a starting point. I don't > see anything else that's concrete on descot.
Here is what Aaron has to say. It looks like it is up to the interested user to move it forward. --- Descot has a very specific purpose: to facilitate the communication between server and client. That is, it is only concerned with the information about code. After reading the following: http://groups.google.com/group/ikarus-users/browse_thread/thread/de82c4f63bef5153 I think that Descot does have an important role to play in the above. The original question was about a package manager. This is a combination of server and client in such a way that Ikarus libraries can be installed on a machine or used by the Ikarus Scheme environment (compiler or interpreter). Descot doesn't care who implements the server, or who implements the client. In this way, the Ikarus folks can either take an existing toolchain and use it, or they can write their own. The important question to ask is what format they are going to use. How will they store and retrieve information about the packages that can be installed, and how will they store and use information about the packages themselves. In this regard, Descot absolutely hopes to shine. Currently, the 1.0 version of the Descot Schema is capable of describing imports, exports, dependencies, and other human oriented meta information, as well as how to download the information, its version, &c. Of particular interest to a package manager is how one will install the package. In this case, I believe that Ikarus has a set of directories that are configured as search directories for libraries. I also believe that most Ikarus libraries are distributed as 'library' forms inside a set of files and a file hierarchy. This information would not have a place in Descot, because it is information about the local system itself. This would be a set of configurations that would occur on a per machine basis. The archive format will likely be best as a simple archive of the files that are extracted to the right location. The rest of the information required for the package manager to work can be defined using Descot's Schema. I encourage people to examine this Schema and try to use it in any new efforts, even though the whole system is still in the Alpha phase, because the Schema is pretty stable right now at version 1.0. The other aspect of a package manager that Descot deals with (in this context) is the way the client and the server communicate. At the moment, protocols exist for the communication of the library data and communicating updates. These could be cached locally or handled remotely by the server. I hope that future repositories will utilize a Descot-compatible interface for communicating about libraries. Most of this is documented in the Technical Documentation (which is still incomplete) available on the website. Part of Descot V1 is the Query server. This is a big task, and I don't know if I am going to have this done by the time the Summer ends, but this is how indexes of data are queried by clients. It will be using the SPARQL interface, maybe with some S-expression extensions, but I want to get the rest of the system written before I do that. This is sort of a layer on top about which it isn't inherently necessary for people worrying about a package manager on Ikarus to worry. This can be written in at a later date without trouble.
