-Design notes
-------------
+public-inbox design notes
+-------------------------
Challenges to running normal mailing lists
------------------------------------------
Use existing infrastructure
---------------------------
-
* public-inbox can coexist with existing mailing lists, any subscriber
to the existing mailing list can begin delivering messages to
public-inbox-mda(1)
Why email?
----------
-
* Freedom from proprietary services, tools and APIs. Communicating with
developers and users of Free Software should not rely on proprietary
tools or services.
There is no need to ask the NSA for backups of your mail archives :)
* git, one of the most widely-used version control systems, includes many
- tools for for email: git-format-patch(1), git-send-email(1), git-am(1).
- Furthermore, the development of git itself is based on the git mailing
- list.
+ tools for for email, including: git-format-patch(1), git-send-email(1),
+ git-am(1), git-imap-send(1). Furthermore, the development of git itself
+ is based on the git mailing list.
* Email is already the de-facto form of communication in many Free Software
communities..
Why git?
--------
-
* git is distributed and robust while being both fast and
space-efficient with text data. NNTP was considered, but does not
support delta-compression and places no guarantees on data/transport
developers. For non-developers it is packaged for all major GNU/Linux
and *BSD distributions. NNTP is not as widely-used nowadays.
+Why perl 5?
+-----------
+* Perl 5 is widely available on modern *nix systems with good a history
+ of backwards and forward compatibility.
+
+* git and SpamAssassin both use it, so it should be one less thing for
+ admins to install and waste disk space with.
+
Laziness
--------
+* Stick to dependencies available in Debian main, this should make it
+ easier for potential users to install, and easier for distro
+ maintainers to pick up.
* A list server being turned into an SMTP spam relay and being
blacklisted while an admin is asleep is scary.
* Avoids bikeshedding about web UI decisions, GUI-lovers can write their
own GUI-friendly interfaces (HTML or native) based on public archives.
- Maybe one day integrated MUAs will feature a built-in git protocol support!
+ Maybe one day integrated MUAs will feature built-in git protocol support!
Web notes
---------
-
* Getting users to install/run ssoma (or any new tool) is difficult.
The web views must be easily read/cache/mirror-able.
* Raw text endpoint allows users to write client-side JS endpoints
without hosting the data themselves (or on a different server).
+What sucks about public-inbox
+-----------------------------
+* Lack of push notification. On the other hand, feeds seem popular.
+
+* some (mostly GUI) mail clients cannot set In-Reply-To headers
+ properly without the original message.
+
+Scalability notes
+-----------------
+Even with shallow clone, storing the history of large/busy mailing lists
+may place much burden on subscribers and servers. However, having a
+single (or few) refs representing the entire history of a list is good
+for small lists since it's easier to lookup a message by Message-ID, so
+we want to avoid splitting refs with independent histories.
+
+ssoma will likely grow its own builtin ref rotation system based on
+message count (not rotating at fixed time intervals). This would
+split the histories and require O(n) lookup time based on Message-ID,
+where `n' is the number of history splits.
+
Copyright
---------
Copyright 2013, Eric Wong <normalperson@yhbt.net> and all contributors.