Index: ossp-pkg/sorp/BRAINSTORM.txt
RCS File: /v/ossp/cvs/ossp-pkg/sorp/BRAINSTORM.txt,v
rcsdiff -q -kk '-r1.1' '-r1.2' -u '/v/ossp/cvs/ossp-pkg/sorp/BRAINSTORM.txt,v' 2>/dev/null
--- BRAINSTORM.txt	2002/10/06 18:40:35	1.1
+++ BRAINSTORM.txt	2002/10/06 18:42:38	1.2
@@ -62,4 +62,34 @@
 ...
 groups...
 
+Possible Approaches
+===================
+
+1. Extending SQUID+unofficial patches
+   Squid selbst kann Reverse Proxy spielen, aber kein Content Rewriting.
+   Fuer Content Rewriting gibt es aber unofficial Patches. Wir muessten
+   also "nur" die Sign-On Funktionalitaet einbauen. Allerdings weisz ich
+   nicht wie gut Squid bei HTTPS als _ORIGIN_ Server ist.
+
+2. Extending Apache2.0+mod_proxy+mod_ssl
+   mod_proxy kann Reverse Proxy spielen, mod_ssl HTTPS reden und der
+   Kernel kann Content-Rewriting. Wir muessten also "nur" die Sign-On
+   Funktionalitaet einbauen als ein mod_sorp. Allerdings ist der Apache
+   2.0 ein dermassener Dreck IMHO (siehe angehaengte Mail), dasz dieser
+   Ansatz zwar sexy klingt, aber irgendwie mir gar nicht recht gefaellt.
+
+3. Extending Pound
+   Pound ist ein recht junger Pthread-basierter HTTP/HTTPS Reverse
+   Proxy, der recht klein und schnuckelig ist und auch leicht
+   erweiterbar. Wir muessten das Content-Rewriting und die Sign-On
+   Funktionalitaet einbauen. Allerdings bin ich mir bei der HTTP
+   Compliance von Pound nicht so recht sicher.
+
+4. Writing OSSP sorp
+   Das ist der ambitionierteste Ansatz. Allerdings auch der sauberste
+   und zukunftstraechtigste. Insbesondere weil wir im OSSP Projekt
+   sowieso eine HTTP Komponente brauchen. Ausserdem haben wir mit den
+   bereits existierenden OSSP Libraries schon fast alle Komponenten
+   beisammen, die wir brauchen um eine eigene Loesung ohne zu groszen
+   Aufwand stemmen zu koennen.