diff options
| -rw-r--r-- | community/gsoc/project_ideas.mdwn | 2 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/apt_ftpfs.mdwn | 87 |
2 files changed, 35 insertions, 54 deletions
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 43f966ad..503dc417 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -94,6 +94,4 @@ will assist you as well as we can. [[inline pages="community/gsoc/project_ideas/secure_chroot" show=0 feeds=no actions=yes]] [[inline pages="community/gsoc/project_ideas/package_manager" show=0 feeds=no actions=yes]] [[inline pages="community/gsoc/project_ideas/debian_installer" show=0 feeds=no actions=yes]] -<!-- [[inline pages="community/gsoc/project_ideas/apt_ftpfs" show=0 feeds=no actions=yes]] ---> diff --git a/community/gsoc/project_ideas/apt_ftpfs.mdwn b/community/gsoc/project_ideas/apt_ftpfs.mdwn index 8c862360..aa4823de 100644 --- a/community/gsoc/project_ideas/apt_ftpfs.mdwn +++ b/community/gsoc/project_ideas/apt_ftpfs.mdwn @@ -8,57 +8,40 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU_Free_Documentation_License|/fdl]]."]]"""]] -[[meta title="Have Debian's apt use ftpfs"]] +[[meta title="Use Internet Protocol Translators (ftpfs etc.) as Backends for Other Programs"]] -\#hurd [[IRC]] channel, 2009-03-13. +The Hurd design faciliates splitting up large applications into independent, +generic components, which can be easily combined in different contexts, by +moving common functionality into separate Hurd servers (translators), +accessible trough filesystem interfaces and/or specialized RPC interfaces. - <tschwinge> By the way: I had another GSoC idea: - <tschwinge> (a) make ftpfs / httpfs unsable enough for... - <tschwinge> (b) have Debian's apt / whetever not use a direct ftp / http - connection, but instead use /ftp/ftp.debian.org/whatever etc. - <tschwinge> (c) Make unionfs unsable enough, so that it can be used - together with nfs (or whatever) to sarve as a cache for /ftp/. - <antrik> uhm... you mean all of this as a single GSoC project? - <antrik> indeed I have the intention of turning ftpfs/httpfs into something - that can be used by other tools instead of a library - <antrik> but that requires them to grow completely new interfaces, making - them suitable for interactive use - <antrik> you are right though that this would be a nice GSoC project... no - idea why I never thought of it in this context - <tschwinge> I think I proposed this idea already some months ago on some - mailing list. - <tschwinge> I don't think it's too much work. - <tschwinge> Or why do you think? - <antrik> it is considerable work - <antrik> it requires implementing a non-trivial, directory based FS - interface - <tschwinge> (c), OK, but why (a) and (b)? - <antrik> also, I'd probably reimplement them on top of libcurl... no need - to maintain our own wheels :-) - <tschwinge> That for sure, yes. But for starterst, we can just take ftpfs - as it is. - <antrik> I think I explained the issues in some past discussion, though I - don't remember where it was - <tschwinge> And just teach apt to open /ftp/... instead of calling whatever - function to retrieve a ftp file. - <antrik> you want progress tracking for one - <antrik> you want the client to see redirects - <antrik> (OK, that might not be necessary for apt-get... it would be - necessary for other use cases like a web browser, though) - <antrik> you want proper error handlin - <tschwinge> http://thread.gmane.org/gmane.os.hurd.bugs/16575/focus=16795 - <antrik> none of this can be expressed by opening a single virtual file - <antrik> it would require adding a completely new interface, either using - custom RPCs, or a directory with several virtual files for various - aspects of the interaction - <antrik> (I prefer the latter variant, though I guess some people would - argue in favour of the former :-) ) - <antrik> anyways, I'll add it to the list - <tschwinge> OK, I see. Nevertheless, don't you think that a more simple - implementation of my idea (also leaving out (c) for now) wouldn't be a - suitable GSoC project? - <antrik> apt-get is probably quite a good example use case for this, so you - are probably right that it would be useful to develop this together - <antrik> (I'll leave out (c) though -- I would consider it a distinct - project. we can place a followup task once (a)+(b) is done :-) ) - <tschwinge> Yes, sure. +Download protocols like FTP, HTTP, BitTorrent etc. are very good candidates for +this kind of modularization: a program could simply use the download +functionality by accessing FTP, HTTP etc. translators. + +There is already an ftpfs traslator in the Hurd tree, as well as a [httpfs +translator on hurdextras](http://www.nongnu.org/hurdextras/#httpfs); however, +these are only suitable for very simple use cases: they just provide the actual +file contents downloaded from the URL, but no additional status information +that are necessary for interactive use. (Progress indication, error codes, HTTP +redirects etc.) + +A new interface providing all this additional information (either as an +extension to the existing translators, or as distinct translators) is required +to make such translators usable as backends for programs like apt-get for +example. + +The goal of this project is to design a suitable interface, implement it for at +least one download protocol, and adapt apt-get (or some other program) to use +this as a backend. + +This task requires some design skills and some knowlegde of internet protocols, +to create a suitable interface. Translator programming knowledge will have to +be obtained while implementing it. + +It is not an easy task, but it shouldn't pose any really hard problems either. + +Possible mentors: Olaf Buddenhagen (antrik) + +Exercise: Make some improvement to one of the existing download translators -- +httpfs in particular is known to be buggy. |