Talk:Tinymail: Difference between revisions
(Tinymail is too fat) |
|||
Line 2: | Line 2: | ||
Tinymail supports SMTP, POP, IMAP and local message stores like mbox, mh, spool and Maildir. Tinymail also has its own local format. |
Tinymail supports SMTP, POP, IMAP and local message stores like mbox, mh, spool and Maildir. Tinymail also has its own local format. |
||
--> You can of course pick which components you will compile. if you don't need SMTP and POP, you don't have to compile that |
|||
This is way too much for OLPC. |
This is way too much for OLPC. |
||
To begin with, the OLPC only needs one message store format which should be shared with all applications which use a message store |
To begin with, the OLPC only needs one message store format which should be shared with all applications which use a message store. |
||
--> You can pick that (and not compile the other formats). So that isn't a problem. |
|||
Given that the 2B1 runs a multitasking OS, it would be best for this message store to be something that can handle multiple processes accessing it at once. If file locking (or record locking) is too complex, the the message store should be owned by a simple daemon which serves all applications. |
|||
--> Tinymail can easily be used to play the role of a service |
|||
⚫ | |||
--> Support for the SEND operation can certainly be done |
|||
but the fact still remains that the 2B1 will not have access to a traditional server infrastructure. |
|||
--> fetchmail the messages into a mbox or Maildir, and/or transfer them over XMPP |
|||
⚫ | Then, the question of network protocols comes to bear. There is not much point in supporting POP and SMTP and IMAP. IMAP itself might make sense, especially if it is extended to have a SEND operation, |
||
The concept of having an application that allows one to manage their received messages archive does make sense, but it needs to be better integrated with the OLPC concepts of networking which means a mesh network, built-in instant messaging and no servers. |
The concept of having an application that allows one to manage their received messages archive does make sense, but it needs to be better integrated with the OLPC concepts of networking which means a mesh network, built-in instant messaging and no servers. |
Revision as of 10:32, 16 November 2006
Tinymail is too fat
Tinymail supports SMTP, POP, IMAP and local message stores like mbox, mh, spool and Maildir. Tinymail also has its own local format.
--> You can of course pick which components you will compile. if you don't need SMTP and POP, you don't have to compile that
This is way too much for OLPC.
To begin with, the OLPC only needs one message store format which should be shared with all applications which use a message store.
--> You can pick that (and not compile the other formats). So that isn't a problem.
Given that the 2B1 runs a multitasking OS, it would be best for this message store to be something that can handle multiple processes accessing it at once. If file locking (or record locking) is too complex, the the message store should be owned by a simple daemon which serves all applications.
--> Tinymail can easily be used to play the role of a service
Then, the question of network protocols comes to bear. There is not much point in supporting POP and SMTP and IMAP. IMAP itself might make sense, especially if it is extended to have a SEND operation,
--> Support for the SEND operation can certainly be done
but the fact still remains that the 2B1 will not have access to a traditional server infrastructure.
--> fetchmail the messages into a mbox or Maildir, and/or transfer them over XMPP
The concept of having an application that allows one to manage their received messages archive does make sense, but it needs to be better integrated with the OLPC concepts of networking which means a mesh network, built-in instant messaging and no servers.