|
|
| Line 1: |
Line 1: |
|
| | #REDIRECT [[Thunderbird/ISPDB]] |
| David Ascher
| |
| | |
| ISPDB will evolve a lot, I'm sure. For example, the idea of ISPs like
| |
| Rick's being able to feed data into it is a fascinating one, but I think
| |
| we should start with baby steps.
| |
| | |
| Here are the first few steps as I see them:
| |
| | |
| Stage 0: what we have now -- we serve a set of static XML files at a
| |
| well known URL, that Thunderbird's autoconfig dialog can poke at,
| |
| indexed by domain. That's all we need to ship Thunderbird 3.
| |
| | |
| Stage 1: we push out the django app which we've been talking about
| |
| mostly, so that we have a minimal, biased-towards-secure,
| |
| simple-but-safe process for soliciting new configurations and validating
| |
| them.
| |
| | |
| The Django app that is currently in draft form has the following design
| |
| criteria:
| |
| | |
| - it's easy for people to submit data (requiring some sort of login
| |
| -- currently openid, cause it's simple and means we don't need to store
| |
| emails or passwords)
| |
| | |
| - only trusted people can label user-submitted data as "verified"
| |
| | |
| - verified data can be exported into the XML format that Thunderbird
| |
| expects.
| |
| | |
| - publishing of those XML files will be done by a (at first) manual
| |
| process of exporting to disk, and svn checkin into the repo that's
| |
| serving the static files, so that we have another review of data changes
| |
| before they go live.
| |
| | |
| End of Stage 1 is defined by: ispdb is live, and we actively solicit
| |
| input from the greater Mozilla community about settings for their ISPs.
| |
| | |
| Stages 2
| |
| - we get feedback based on stage 1 being live
| |
| - we analyze the logs from the autoconfig HTTP GET calls to find out
| |
| what domains people are asking for, so we can proactively look for
| |
| configuration information for those domains
| |
| - we automate the export from the django app to svn
| |
| - we put in some process for revocation
| |
| | |
| later:
| |
| - we build in some karma notions, so we can reward good
| |
| contributors/reviewers.
| |
| - we increase the scope of ISPs we target (e.g. Exchange servers?)
| |
| - we increase the scope of kinds of data we publish (more than email?)
| |
| | |
| even later:
| |
| - we internationalize the site
| |
| - we actually serve from django directly (with a suitable caching
| |
| proxy in front)
| |
| | |
| ------
| |
| | |
| I'd strongly encourage that we focus on what's needed to get to Stage 1,
| |
| so that we have something to do Stage 2 with =). To that end, here are
| |
| some of the things I suspect we need to have in place, and some ideas as
| |
| to who could do what.
| |
| | |
| - a test suite, so we feel more confidence in changing code. In
| |
| particular, I think it's critical that we test the code that does
| |
| "import from XML -> export to XML", and makes sure that that is not
| |
| lossy =). [students]
| |
| | |
| - more testing from people acting as users, and acting as reviewers,
| |
| to expose issues in the user experience of both of those scenarios.
| |
| [students, everyone] | |
| | |
| - a feature that given an ISP configuration, does some sanity
| |
| checking, to try and avoid security issues -- check that hostnames are
| |
| subdomains of the email domain in question, sanity check against known
| |
| bad actors somehow.
| |
| | |
| - publish documentation on the rules that we're following to approve a
| |
| configuration. My current draft is something like:
| |
| | |
| - configuration information is available on a public web page that
| |
| is clearly affiliated with the main owner of the domain (not on some
| |
| bboard or newsgroup).
| |
| - said configuration information is in a language that one of the
| |
| trusted people speaks
| |
| - passes sanity-check enforced by the backend.
| |
| | |
| - some scripts for gozer to test the exporting / checkin / publishing
| |
| phase. [gozer?]
| |
| | |
| - until we have some more confidence in the data, I'd suggest that we
| |
| do daily backups of the sqlite DB, to go along w/ our changes to the
| |
| code [gozer].
| |
| | |
| - we probably want some better looking graphics, but that can be late
| |
| in the process. [rebron]
| |
| | |
| - we probably want some editorial review of the words on the page. [??]
| |
| | |
| - we want a clear deployment plan, with the /admin URL probably
| |
| behind a MoMo certificate, which we can issue to any trusted person. [gozer]
| |
| | |
| ----
| |
| | |
| I think stage 1 is doable in a small number of weeks, because I think
| |
| what we have isn't a very complicated system. If there are things that
| |
| strike people as complicated, _please_ point them out, I'm completely
| |
| happy to revise the requirements to make it less complicated.
| |
| | |
| Feedback, questions?
| |
| | |
| --david
| |
| | |
| PS: ISPDB is woefully underdocumented. If someone wanted to start
| |
| authoring some wiki pages that collects some of the various bits of
| |
| writing (such as this one) on it, feel free.
| |