1.HTTP uses a TCP connection. For that matter so does SMTP and IMAP and the proposed REMAP.
Yes, of course. He is not claiming that TCP is bad, but rather that it is too low-level. i.e. One wants an application protocol (e.g. HTTP, SMTP, IMAP) rather than a transmission protocol (e.g. TCP).
The HTTP verbs should be sufficient for email, so why not leverage them?
It's not yet clear that people prefer tags to folders. After all, monkeys don't expect a banana to be in two boxes at once.
Heh, dare I reply? Tags can be used as pigeonholes, and this can be enforced if desired. But why? Tags are so much more useful because they are not pigeonholes.
Here is a classic example:
Does my app config go in a system directory or an app directory or a config directory? the executables? the daemon? the log files?
The classic approach is to put system-level config files under /etc, log files under /var/log, executables and daemons in various locations, etc. Some newer approaches (HomeBrew, GoboLinux, etc) keep everything organized per-application.
Instead, keep every file in the global folder / namespace. Tag the executables as exe, the log files as log, config as cfg, and also tag everything with the app's name. Possibly the version, etc.
A file is uniquely identified by its tags and its name. Any combo can be used, so long as it doesn't already exist.
You don't have to make painful decisions about the unique place in the tree that a piece of information should exist. Just tag it appropriately and move on. The tag system could even create an optimal concrete hierarchy based on tag and tag association metrics if needed.
But the server will have to know it to send it. Granted, IMAP is for receiving, and SMTP is for sending, but something in the chain has to know MIME.
I'm not sure if this is GoF, but this sounds like the classic gateway pattern. You put MIME gateways at the edges of the new email network. MIME-only servers must go through the gateways.
Your intended point about pigeonholes can sometimes backfire within the context of email. Consider a Gmail user who sends a query to a number of different recipients, expecting unique replies from each. Gmail, because of the like headers, will group all of the responses into the parent conversation. Let's say the users tags the first response with a label corresponding to that sender, and then the second response comes in. At this point, the user is at an "oh shit" moment, finally comprehending the implications of Google's labeling of conversations rather than individual messages.
You need to be able to specify both parent and child tags to be able to facilitate search and give users something that isn't too confusing re: organization.
I understand the pigeonhole filing example, but I quit "filing" years ago. It's tedious. Tagging also takes too much thought, particularly at recall time: did I tag that "development" or "programming"? I just use search.
I have a script that monitors my desktop. Any file not modified within the past 8 hours is moved to a folder dated for the end of this week. That gives me 52 folders a year, granular enough to find a file manually if I know roughly when I dealt with it.
My desktop stays clean except for what I'm actively working on, and I don't look for files hierarchically or by category/tag. To find something, I use Spotlight search. That's faster than navigating a folder hierarchy would be even if I knew exactly where the file was.
That's also why I love Gabor's reMail on the iPhone.
> and then the second response comes in. At this point, the user is at an "oh shit" moment, finally comprehending the implications of Google's labeling
I am having trouble understanding what the problem is, here. I also suspect this may be a Gmail problem rather than a tagging problem.
It's tagging a conversation rather than tagging an email.
I frequently put different emails from the same conversation in different folders, because they contain different types of information that I need to do different things with.
Yes, of course. He is not claiming that TCP is bad, but rather that it is too low-level. i.e. One wants an application protocol (e.g. HTTP, SMTP, IMAP) rather than a transmission protocol (e.g. TCP).
The HTTP verbs should be sufficient for email, so why not leverage them?
It's not yet clear that people prefer tags to folders. After all, monkeys don't expect a banana to be in two boxes at once.
Heh, dare I reply? Tags can be used as pigeonholes, and this can be enforced if desired. But why? Tags are so much more useful because they are not pigeonholes.
Here is a classic example:
Does my app config go in a system directory or an app directory or a config directory? the executables? the daemon? the log files?
The classic approach is to put system-level config files under /etc, log files under /var/log, executables and daemons in various locations, etc. Some newer approaches (HomeBrew, GoboLinux, etc) keep everything organized per-application.
Instead, keep every file in the global folder / namespace. Tag the executables as exe, the log files as log, config as cfg, and also tag everything with the app's name. Possibly the version, etc.
A file is uniquely identified by its tags and its name. Any combo can be used, so long as it doesn't already exist.
You don't have to make painful decisions about the unique place in the tree that a piece of information should exist. Just tag it appropriately and move on. The tag system could even create an optimal concrete hierarchy based on tag and tag association metrics if needed.
But the server will have to know it to send it. Granted, IMAP is for receiving, and SMTP is for sending, but something in the chain has to know MIME.
I'm not sure if this is GoF, but this sounds like the classic gateway pattern. You put MIME gateways at the edges of the new email network. MIME-only servers must go through the gateways.