[<--] Indice [-->]

From marc0 <marc0@autistici.org>
Date Sat, 19 Jul 2003 19:58:17 +0200
Subject [hackmeeting] file-server-over-messages.el 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bozza finale prima dell'implementazione, sono benvenuti suggerimenti e
derisioni.

;;; file-server-over-messages.el  ---  File server over messages.

[snip]

;;; Commentary:

;; Index:
;; 
;;   1. Introduction
;;   2. Overview
;;   3. name-server design
;;   4. file-server design
;;   5. Implementation
;; 
;; 1. Introduction
;; 
;;   ARPA messages are very good vehicles for informations in general,
;;   and not only messages.
;; 
;;   Some strong points of the ARPA messages are:
;; 
;;     a) decentralized: for example using chains of NNTP and mailing
;;        lists;
;;     b) and so rendundant;
;;     c) and distributed;
;;     d) flexible: decades of use of ARPA messages, many clients and
;;        servers for ARPA messages, over different flavours of
;;        network;
;;     e) easy to implement: most of the infrastucture is already
;;        designed, implemented, and tested;
;;     f) fast;
;;     g) easy to use;
;;     h) extensible: ARPA messages proved to be very very very
;;        extensible;
;; 
;;   Web (HTTP) and FTP and likewise are not so strong services, for
;;   example making mirrors requires more effort, and to give write
;;   access there is needed to give away logins and passwords, so more
;;   effort.
;; 
;;   So the `file-server-over-messages' system is meant to replace Web
;;   and FTP with a more scalable, distributed, pratical system.
;; 
;;   So the `file-server-over-messages' system target is to give,
;;   especially to who has not many resources, a more scalable,
;;   distributed, less-effort-sucking way to publish their contents.
;; 
;; 2. Overview
;; 
;;   The system is made of three parts:
;; 
;;     a) an ARPA messages vehicle (for example an NNTP server);
;; 
;;     b) the file-server-over-messages software.
;; 
;;   So, the file-server-over-messages has the following functions:
;; 
;;     a) pushing files throught some interface (for example: UI (a
;;        program), library function (a library), HTTP (web gateway):
;; 
;;        a1) get the request through the frontend,
;;        a2) look in the names table for the article number and part,
;;        a3) get from the ARPA backend the article,
;;        a4) get the wanted part from the article,
;;        a5) push it to the client;
;; 
;;     b) handling the `filename <--> article number and part' table:
;; 
;;        b1) get the request of modification through the ARPA backend
;;        b2) parse the message
;;        b3) verify permissions
;;        b4) modify the table if needed
;; 
;;   We will call the `a' part `file-server' and the `b' part
;;   `name-server'.
;; 
;;   The cool thing would be to make the file-server-over-messages truly
;;   independent from the ARPA messages vehicle, not requesting any
;;   special feature in the vehicle (vehicle can be for example an NTTP
;;   server) or any special header or format in the messages.
;; 
;;   Why all this? The motivation is that people that have to use more
;;   bandwidth than how much they can get can use public services.
;; 
;;   The name-server must be capable to use another vehicle for its own
;;   communication than the file-server.
;; 
;;   This because it seems good to not put a limitation on this.
;;
;; 3. name-server design
;;
;;   The name-server will read some messages, parse these messages,
;;   verify them using an implementation of PGP, and then executing
;;   the requested operation if all is OK.
;;
;;   The operations are all meant to edit the alias table:
;;     - add an alias
;;     - remove an alias
;;     - modify an alias
;;
;;   The alias table is a list of lists of four attributes: the alias,
;;   the message-id of the article in which the file is contained, the
;;   part number in which the file is contained, and finally a list of
;;   strings containing PGP fingerprints, these fingerprints are the
;;   ones of the persons that can edit or remove the alias, so the
;;   owners of the alias.
;;
;; 4. file-server design
;;
;;   When the file-server receives a query for a file, it checks if
;;   the file is in the alias list, in a negative case it returns 404
;;   (page not found).
;;
;;   If it can find an alias for the page, it checks if the file is in
;;   a private folder, if not it retrieves the files, the file part
;;   and returns it, else returns 404 (page not found).
;;
;; 5. Implementation
;;
;;   This implementation will be based on Emacs, Gnus, httpd.el and
;;   httpd-serve.
;;
;;   This implementation will require a dedicated user and home
;;   directory.
;;
;;   This user will be an Emacs user, it will run Emacs/Gnus, reading
;;   news now and then, doing things, replying, serving pages, etc...

[snip]

- -- 
marc0@autistici.org (rot13-string "znep0@pelcgberoryf.arg")
2143 9E77 D5E6 115A 48AD  A170 D0EE F736 4E88 99C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/GYYA0O73Nk6ImcIRAtEQAKCxwAthzeht6Qociko4dKfhhP6vmwCghmLF
j+emsZmoM2lFBsfYf+yKljY=
=0dtu
-----END PGP SIGNATURE-----
_______________________________________________
hackmeeting mailing list
hackmeeting@kyuzz.org
http://lists.kyuzz.org/mailman/listinfo/hackmeeting
[<--] Indice [-->]