|
Check-in Number:
|
2558 | |
| Date: |
2002-Oct-06 20:42:38 (local)
2002-Oct-06 18:42:38 (UTC) |
| User: | rse |
| Branch: | |
| Comment: |
remember issues from last week |
| Tickets: |
|
| Inspections: |
|
| Files: |
|
ossp-pkg/sorp/BRAINSTORM.txt 1.1 -> 1.2
--- 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.
|
|
