Vladimir Panteleev Wrote:

> On Sun, 28 Jun 2009 15:44:04 +0300, Lester L. Martin II  
> <lestermarti...@gmail.com> wrote:
> 
> > I was a bit skimpy on the projects plan. It's supposed to end up being a  
> > D Installer in D for multiple compiler sets, libraries, and some other  
> > stuff and it would use DSSS net to get all these different things once I  
> > completed that DSSS Net thing. It would end up being like a "package  
> > manager" for D because it could upgrade, downgrade and so much more such  
> > as resolve conflicts between libraries ("No, you are not allowed to  
> > install that because it is not going to work with what you got, can I  
> > recommend you X instead, oh, ok you said no, do you want to install  
> > anyway, gosh, you said yes, I'll continue, but don't say I didn't warn  
> > ya"). Of course that type of resolving feature wasn't going to make it  
> > into first release because that's particularly hard. The upgrade feature  
> > would upgrade or fail and not upgrade anything. the downgrade feature is  
> > a "just in case" feature. Of course, most of this is conceptual at the  
> > moment, though I have a lot of the backend of a DSSS net thing written,  
> > I have yet to give it the hooks required to download, and install, and  
> > have yet to give it a simple command line interface.
> 
> Judging by SVN [1] there isn't much to look at at the moment, so I had a  
> look at the XML example [2]. Some questions:
> 
> 1) Why do you have a list of downloads? Are these supposed to be mirrors?  
> Or does each one represent a version?
> 2) What's the difference between package dependencies and download  
> dependencies?
> 3) Why are the package dependencies in human-readable format (and include  
> Internet location) rather than reference another package by name?
> 4) Same for download dependencies - aren't a package identifier and  
> version sufficient for a dependency declaration?
> 5) I don't think installation instructions can be described in only shell  
> commands...
> 
> Sorry if that was a very rough draft and your actual design isn't  
> challenged by these questions.
> 
> [1]  
> http://dsource.org/projects/dinstaller/browser/trunk/D/Dinstaller%20in%20D
> [2] http://www.dsource.org/projects/dinstaller/wiki/pdesc
> 
> -- 
> Best regards,
>   Vladimir                          mailto:thecybersha...@gmail.com

The naming of the project is probably incorrect (since I didn't really worry 
about it compared to the code), a more complete one is (here 
http://fsdev.net/repositories/browse/dsss/trunk/backend ) but I haven't merged 
some of my changes and besides that, I think those changes were lost in my last 
windows crash (since I was on windows then if I'm correct). However, it's a 
pretty good starting point. Some of it may need to be updated to latest tango 
though. At the moment it's a framework pretty much where the application has 3 
layers.. the framework, which is protocol independant, the protocol dependant 
stuff (ftp/http/SOMEODDCREATION) that is a basic set of hooks that comply to a 
certain function definition and when initing the backend, hook itself into it 
to get the stuff over the protocol, and then their is the command line level 
which controls managing all this.... 
http://fsdev.net/repositories/browse/dsss/trunk/backend It's got the backend 
pretty much finished if I remembe!
 r correctly and I had started works on the midend hooks for http and ftp, and 
then lost that work. It shouldn't be super hard if I remember correctly and it 
should also all compile (if I remember correctly).

Reply via email to