Very glad to hear you're interested in my system Bjørn.<br><br><div><span class="gmail_quote">On 8/16/07, <b class="gmail_sendername">Bjørn Stabell</b> <<a href="mailto:bjorn@exoweb.net">bjorn@exoweb.net</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Aug 15, 2007, at 21:34, Arve Knudsen wrote:<br>> These are some interesting points you are making. I have in fact
<br>> been developing a general software deployment system, Conduit, in<br>> Python for some time, that is capable of supporting several major<br>> platforms (at the moment: Linux, Windows and OS X). It's not
<br>> reached any widespread use, but we (at the Simula Research<br>> Laboratory) are using it to distribute software to students<br>> attending some courses at the university of Oslo. Right now we are<br>> in the middle of preparing for the semester start, which is next week.
<br>><br>> The system is designed to be general, both with regard to the<br>> target platform and the deployable software. I've solved the<br>> distribution problem by constructing an XML-RPC Web service, that
<br>> serves information about software projects in RDF (based on the<br>> DOAP format). This distribution service is general and independent<br>> of the installation system, which acts as a client of the latter.
<br>><br>> If this sounds interesting to you I'd love if you checked it out<br>> and gave me some feedback. It is an experimental project, and as<br>> such we are definitely interested in ideas/help from others.
<br><br>Hi Arve,<br><br>That's an interesting coincidence! :)<br><br>Without turning it into a big research project, it would be<br>interesting to hear what you (honestly) thought were the strengths<br>and weaknesses of Conduit compared to, say, deb/rpm/ports/emerge,
<br>whichever you have experience with. I did download and look at<br>Conduit, but haven't tried it yet.</blockquote><div><br>I would say the main difference lies in how Conduit is designed to be a completely general solution for distributing software and deploying it on user's systems, with as loose coupling as possible. You could say that what I am trying to achieve is closer to MacroVision's Install Anywhere / Flexnet Connect than to monolithic package managers such as APT, Emerge etc. The former offers a complete solution to independent providers for letting them deliver software and maintain it (with updates) over time, while the latter is a tightly integrated service which is even used to implement operating systems (
e.g. Debian, Gentoo).<br> <br>Conduit tries to offer the best of both worlds by building a central software portal from independent project representations. The idea is that software providers maintain their own profile within the portal service, and associate with this a number of projects which are described in RDF (an extension of the DOAP vocabulary). The portal service accumulates these data, and expose them to installation agents via a public XML-RPC API.
<br><br>I've written a framework for Conduit agents that currently supports installing on Linux, Windows (XP/Vista) and OS X. I find it a great strength to be able to offer a common installation system for all three platforms, but the weakness is that generally it doesn't integrate as well with the operating systems as native installers do.
<br><br>On Windows at least I plan to piggy-back on the native installation service (Windows Installer), to achieve better integration without having to reinvent the wheel. On Linux it is worse since there is no well-defined native installation service, but instead a bunch of different packaging systems which overlap with my own deployment model (specification of dependencies etc.).
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">There are so many ways to take this, and so many "strategic"<br>decisions that I'd hope people on the list could help out with.
<br><br>Personally I think it would be great if we had a strong Python-based<br>central package system, perhaps based on Conduit. I'm pretty sure<br>Conduit would have to have the client and server-side components even
<br>more clearly separated, though, and the interface between them open<br>and clearly defined (which I think it is, but it would have to be<br>discussed).</blockquote><div><br>The client and server components should be clearly separated as-is, but the server API should definitely be reviewed and properly defined. Conduit-specific support exists on the server as extensions (namespace "conduit") of the RDF vocabulary.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I see Conduit (and PyPI) supports DOAP, and looking around I also<br>found <a href="http://python.codezoo.com/">
http://python.codezoo.com/</a> by O'Reilly; it also seems to have a<br>few good ideas, for example voting and some quality control (although<br>that's a very difficult decision, I guess).</blockquote><div><br>CodeZoo is a very interesting initiative. I let myself inspire in part by CodeZoo when I started designing Conduit, but mostly by SWED (
<a href="http://swed.org.uk">http://swed.org.uk</a>) which has a similar model of accumulating decentralized information in RDF for centralized access (via a Web interface). I would actually like Conduit's distribution service to evolve into something with similar functionality to CodeZoo. A rich Web interface for navigating the catalog of software would be awesome (an alternative to sourceforge?). I've also pondered the possibility of user profiles in the portal so that one can keep preferences centrally, for instance as a way to define personal "installation sets" (
e.g., after installing a new Linux, restore your previous installations).<br></div><br></div>Arve<br>