Local IMAP server

[Gus Mueller]

Just a quick email to hopefully end this discussion- Letters isn't going to install a local IMAP server.

If someone wants to write a plugin that does this, or install one themselves, well… knock yourself out. But that's not how local folders would be managed in Letters.

-gus

--

August 'Gus' Mueller
Flying Meat Inc.
http://flyingmeat.com/

[John C. Welch]

Post by Gus Mueller
Just a quick email to hopefully end this discussion- Letters isn't going to
install a local IMAP server.
If someone wants to write a plugin that does this, or install one themselves,
wellŠ knock yourself out. But that's not how local folders would be managed
in Letters.

Oh

Thank

God

(or Gus in this case)

[Brent Gulanowski]

My idea was that using a plug-in format for mailbox access would allow
someone to do so without needing to modify or fork the codebase, and ensure
clean partitioning of functionality, amongst other design benefits -- NOT
that Letters SHOULD include one. It is, however, an interesting idea, and
the complexity of doing so has been exaggerated.

Many programs ship with embedded servers of one sort or another, running on
localhost and not accepting external network connections (for security
reasons). There are numerous design and implementation benefits. That's why
it's a good idea as an extension. Moreover, for numerous reasons, not least
of all testing, it would be quite valuable as an alternative to whatever
local caching architecture is eventually developed.

I've shipped (as part of a team) a product which uses an embedded server as
part of its design, and I can vouch for the benefits. I might even wager
that such a design would have higher reliability than a custom solution, in
real world application, especially in terms of scalability. I hope someone
implements such a variation for comparison's sake. It could be very
enlightening.

Post by Gus Mueller
Just a quick email to hopefully end this discussion- Letters isn't going to
install a local IMAP server.
If someone wants to write a plugin that does this, or install one
themselves, well… knock yourself out. But that's not how local folders
would be managed in Letters.

[DINH Viêt Hoà]

Hello,

Note that synchronization of all messages has to be done to index the
messages so that search of emails is very fast.
To do indexing, we have to :
- fetch the message
- add this to the index
- store the list of messages that have been indexed

When this implementation is done, adding the cache will not be a big
amount of work.

Moreover, storage of the emails in a database is a specific format
will allow us to reach good performance when we want to show a mailbox
of thousands messages.
-> we won't have to parse messages.

"Letters isn't going to install a local IMAP server." -- Gus Mueller

Regards,

Post by Brent Gulanowski
My idea was that using a plug-in format for mailbox access would allow
someone to do so without needing to modify or fork the codebase, and ensure
clean partitioning of functionality, amongst other design benefits -- NOT
that Letters SHOULD include one. It is, however, an interesting idea, and
the complexity of doing so has been exaggerated.
Many programs ship with embedded servers of one sort or another, running on
localhost and not accepting external network connections (for security
reasons). There are numerous design and implementation benefits. That's why
it's a good idea as an extension. Moreover, for numerous reasons, not least
of all testing, it would be quite valuable as an alternative to whatever
local caching architecture is eventually developed.
I've shipped (as part of a team) a product which uses an embedded server as
part of its design, and I can vouch for the benefits. I might even wager
that such a design would have higher reliability than a custom solution, in
real world application, especially in terms of scalability. I hope someone
implements such a variation for comparison's sake. It could be very
enlightening.

Post by Gus Mueller
Just a quick email to hopefully end this discussion- Letters isn't going
to install a local IMAP server.
If someone wants to write a plugin that does this, or install one
themselves, well… knock yourself out.  But that's not how local folders
would be managed in Letters.

--
#pragma mark signature
You"];
_______________________________________________
List help: http://lists.ranchero.com/listinfo.cgi/letters-dev-ranchero.com

[John C. Welch]

My idea was that using a plug-in format for mailbox access would allow someone
to do so without needing to modify or fork the codebase, and ensure clean
partitioning of functionality, amongst other design benefits -- NOT that
Letters SHOULD include one. It is, however, an interesting idea, and the
complexity of doing so has been exaggerated.

Not by people who have permanent schedules for applying security patches to
server software. Who maintains the server code for security and other
updates? Well, we know who should, it¹s the Letters team, but that¹s not
really a team is it. If gus decides, ³fuckit, I¹m done² then who takes over?
Someone. Or, no one. Meanwhile, what do the people who are power users but
can¹t write code do? This issue sucks in the world where you have money, and
SLAs to use as leverage, exactly what leverage does someone relying on an
open source project with a random set of developers have? None. So now users
have to maintain that server code.

Many programs ship with embedded servers of one sort or another, running on
localhost and not accepting external network connections (for security
reasons). There are numerous design and implementation benefits. That's why
it's a good idea as an extension. Moreover, for numerous reasons, not least of
all testing, it would be quite valuable as an alternative to whatever local
caching architecture is eventually developed.

Many programs do, because they have a need for server-like functionality,
and in that instance, that decision makes sense. This is an email client. It
has to be of use to people who can re-write the code in their sleep and
those who couldn¹t identify objective c with a book and a gun at their head.
Both ends of that list are part of the group known as ³Power users² and if
you don¹t want non-code writers using this application, then again, have
some honesty and say ³I know we said power users, but we¹re really designing
this for programmers. If you aren¹t a programmer, then this is not the
client for you, and you shouldn¹t use it.² That sucks, but it is honest and
sets expectations correctly. However, if you are going say ³You don¹t have
to know squat about programming, or really even IMAP to use this, this
designed for people with really heavy email loads who need a client that can
keep up², and you want to ship a product that has a server in it, and you
are not able to fully commit to the workload that supporting, updating and
testing just the server provides, then it is hypocritical to advocate one.

I've shipped (as part of a team) a product which uses an embedded server as
part of its design, and I can vouch for the benefits. I might even wager that
such a design would have higher reliability than a custom solution, in real
world application, especially in terms of scalability. I hope someone
implements such a variation for comparison's sake. It could be very
enlightening.

All applications are not the same. Your application may actually act AS a
server, (and I¹ve a pretty good idea that it does), so in that case, it
makes perfect sense to have that functionality. Who takes responsibility
for that code? That team and that company. If a third party finds a security
hole in your server, your customers and users know who to go to for
information on patching that hole, and they know that they¹ll get an update
that will take care of it, not ³you have the source, do it yourself, I¹m no
longer interested in that project.²

Using a server as an intermediary to read files off a hard drive that aren¹t
handled by the (already there) caching code may be a nice intellectual
exercise, but this thing has to be usable by the entire set of intended
users, not just the ones that can custom patch code.