Re: Send Gmail to Evernote

February 13, 2013

175x175

Harry Oosterveen published today this nice review:

Send Gmail to Evernote: an overview of the tools

The review mentioned our InQloud service that is available in Evernote trunk.

The summary table says “only notebooks” in the notebook/tags column, and that needs to be corrected. Harry posted the correction in the comments. Tagging is easy with inQloud: https://inqloud.uservoice.com/knowledgebase/articles/134619-custom-addresses-for-notebook-tags

-Alexey

BigDripper is our new follow-up robot that leverages Yoxel email conversation tracking. Currently it is only available for Gmail users. You will need to configure at least one Google Apps service in Yoxel Portal to be able to use BigDripper.

To see BigDripper in action please visit the blog post written by an early adopter.

-Alexey

I’ve been working with Gmail using javamail library for a long time now, the standard IMAP/SMTP capabilities were quite enough, even to deal with the labels. But recently I decided to also pull the gmail custom attributes: X-GM-THRID and X-GM-LABELS (see Gmail Imap Extensions).

At first it looked like there was no easy way to fetch those custom attributes using the standard javamail FetchProfile mechanism so I went searching in Google.

I found the  java-gmail-imap project which was quite encouraging but after studying it more I figured that I did want to use it:

  1. It incorporated javamail 1.4.4 and I really needed some new 1.5.x functionality
  2. A lot of original javamail classes if not all were extended/re-written which seemed like an overkill
  3. Last release was on Mar 23, 2012

So I went exploring further.

I must say that I really do appreciate that so much code these days is open source. Both java-gmail-imap and javamail sources showed me what was really happening under the hood and I came up with a simpler hack which only requires one extended class.

I’ll explain the hack here and if you want my code let me know.

So, for a list of messages that I am reading from Gmail I now do a standard javamail profile fetch:

folder.fetch(msgs, stdFetchProfile);

followed by my custom fetch using IMAPFolder’s doCommand():


final MessageSet[] mSets = MessageSet.createMessageSets(mns);
((IMAPFolder) folder).doCommand(new IMAPFolder.ProtocolCommand() {

	@Override
	public Object doCommand(IMAPProtocol p) throws ProtocolException {
		try {
			Response[] r = p.fetch(mSets, "X-GM-LABELS X-GM-THRID");
			for (int i = 0; i < r.length; i++) {
				if (!FetchResponse.class.isInstance(r[i]))
					continue;

				// Got a FetchResponse.
				GmailFetchResponse gfr = new GmailFetchResponse(
								((FetchResponse) r[i]).toString());
				// Use gfr.getNumber() to get the msg number
				for (int j = 0; j < gfr.getItemCount(); j++) {
					Item item = gfr.getItem(j);
					if (X_GM_LABELS.class.isInstance(item))
						// get the labels
						((X_GM_LABELS) item).x_gm_labels);
				}
			}
		} catch (ProtocolException e) {
			logError(e.getMessage(), e);
		}
		return null;
	}
});

GmailFetchResponse is the class I had to create by extending Javamail’s Response. It’s aware of the X-GM-* attributes and I make it re-parse the response received in the standard FetchResponse. I used only the required part of the java-gmail-imap’s parse() method:

private void parse() throws ParsingException {
		skipSpaces();
		if (buffer[index] != '(')
			throw new ParsingException(
					"error in FETCH parsing, missing '(' at index " + index);

		Vector v = new Vector();
		Item i = null;
		do {
			index++; // skip '(', or SPACE

			if (index >= size)
				throw new ParsingException(
						"error in FETCH parsing, ran off end of buffer, size "
								+ size);

			switch (buffer[index]) {
			case 'X':
				if (match(X_GM_MSGID.name)) {
					index += X_GM_MSGID.name.length;
					i = new X_GM_MSGID(this);
				}
				if (match(X_GM_THRID.name)) {
					index += X_GM_THRID.name.length;
					i = new X_GM_THRID(this);
				}
				if (match(X_GM_LABELS.name)) {
					index += X_GM_LABELS.name.length;
					i = new X_GM_LABELS(this);
				}
				break;
			default:
			}
			if (i != null)
				v.addElement(i);
		} while (buffer[index] != ')');

		index++; // skip ')'
		items = new Item[v.size()];
		v.copyInto(items);
	}

X_GM_LABELS* classes I copied from java-gmail-imap project, they’re very simple. I only added required UTF-7 conversion:

public class X_GM_LABELS implements Item {

	static final char[] name = { 'X', '-', 'G', 'M', '-', 'L', 'A', 'B', 'E', 'L', 'S' };
	public int seqnum;

	public String[] x_gm_labels;

	public X_GM_LABELS(GmailFetchResponse r) throws ParsingException {
		seqnum = r.getNumber();
		r.skipSpaces();
		x_gm_labels = r.readAtomStringList();
		if (x_gm_labels != null)
			for (int i = 0; i < x_gm_labels.length; i++)
				try {
					x_gm_labels[i] = new String(
							x_gm_labels[i].getBytes("US-ASCII"),
							"X-MODIFIED-UTF-7");
				} catch (UnsupportedEncodingException e) {
					e.printStackTrace();
					break;
				}
	}
}

That is all. With one additional custom fetch call (which is not a huge overhead) you have read the Gmail attributes for your messages.

I hope this can be useful for others.

-Alexey

Is Your Inbox Overflowing?

January 24, 2011

I ran into this article today, It’s time to deal with that overflowing inbox, which re-iterates what we all experience with email today:

1) The growing number of e-mails, she explained, is hampering productivity among so-called knowledge workers who rely heavily on e-mail to get their jobs done and to stay on top of their personal lives.

2) “People with more than 100 messages in their inbox are less satisfied with the quality of their projects, more behind on them, and less likely to know what they need to work on at the start of a workday,”  …

 

And another interesting fact, pointing out that corporate knowledge workers use email alot for project collaboration:

Right now, the average corporate employee spends 25 percent of his or her workday on e-mail-related tasks, according to Radicati, compared to 14 percent on face-to-face meetings and 9 percent on the phone.

The article suggests to clean-up your inbox regularly and delete email.  But that, I think, is the option you’re left with when using your traditional email client. Email may contain valuable data and so removing it regularly just to make yourself more productive is not the best approach. I believe, organizing email better in ways that make it easy to find and know what is important at the moment, is the way to go.

You’ll probably need an additional app for this, or a new generation email client. GMail is a good one, but how do you manage your MS Exchange email with it? Xobni is an app that could help you with that though.  We’re also developing the Yoxel PCM app that will help you manage email threads/conversations better for more productive project management.

Cheers

Email or Email Client?

January 12, 2011

Great article from 4spires,  Email Is Flawed For Managing Work – Transformation Is Coming.

Despite our collective understanding that email is flawed as a workflow management tool, we are firmly entrenched in its use.  What is needed is a generic solution that mirrors the simplicity and flexibility of email but adds better workflow tracking and management reporting features.

As I wrote in my earlier post, Email vs. social networking in your workplace, I would separate the term “email” as a messaging system/infrastructure (as defined by RFC822, RFC2821 (smtp), RFC2045 (mime), RFC3501 (imap), …) from “email” as email client software for reading/sending/managing email messages, implementing only a specific use model, usually dated 10-15 years ago. And so when it comes to the email clients I really agree with the article, most email clients are outdated and have not kept up with the workflow management requirements so it is obvious that new generation email management apps need to be developed.

Email as the messaging infrastructure is actually quite solid in my opinion and can be leveraged quite successfully by those new generation tools. I am probably quite “old school” but I love email. BTW, see the comment for that article about the recent Skype outage, could this have ever happened to email and paralyze millions communication channels? What I believe is that simple and open wins and email is simple and based on open standards so there could simply be a better email client that is also designed to enhance the workflow management.

I have to admit though that I am quite biased in my opinion because we’re working on a tool like that ourselves. We simply want to leverage the email based collaboration model that most organizations use today (many of which are MS Outlook based). I think most organizations have chosen to use email for a good reason (flexibility, simplicity, ubiquity, you name it …), so lets just go with what already seems natural and enhance the experience.

Here is how you could implement basic scrum story tracking without signing up with any project server, simply using email. You’ll need to use our desktop app Yoxel PCM which scans your email inbox to help you track conversations and identify requests communicated in them.

  1. Install Yoxel PCM, connect it to your email account (i.e. GMail), see how here
  2. Flag/Star those email threads that represent scrum stories in your email client (or start new ones directly from Yoxel PCM)
  3. Yoxel PCM starts tracking conversations that you have identified and also presents them to you as chats
  4. As a conversation progresses, requests and responsible persons are identified.
  5. Each responsible person marks his/her ownership of a story and attaches personal tasks to it, all in their own Yoxel PCM. All this info is shared with the rest of the To/CC list and everyone is aware of who the owners are.
  6. As the owners progress on their tasks they mark their status (active, inwork, complete). As the matter of fact the app can tell the 1st two states automatically. Others, monitoring the conversation, see all these updates.

With this server-less model you dont get to see gantt or burndown charts but you can track all stories simply over email and empower individual functional members to plan and track the tasks associated with them.

Enjoy.

You must have seen the Dec 6 article in the SF Chronicle entitled “Transformation of e-mail is under way“, talking about Facebook’s move into email. The last few paragraphs of the article really summarize the message:

That consumer-driven demand is part of the reason Facebook’s first stab at a unified messaging system is noteworthy, said analyst Rob Koplowitz of Forrester Research Inc. Facebook has more than 500 million users, and they are increasingly bringing social networking into the workplace, a trend that has accelerated in the past five years.

With a business communications system built around a social network rather than just e-mail, employees can learn about projects their co-workers are doing or check profiles to find who might have the expertise they seek.

“It’s surprising how much we can share that we don’t share today,” he said. “The tools we have were all designed to think security first, share later.”

The need for e-mail, though, won’t go away, but a program that just does e-mail may not be around in 10 years, he said.

“You’ll still have a messaging engine, but that engine will probably be wrapped around other communication and collaboration technologies,” he said.

This and other articles often talk about email, that as a messaging system it may not survive. I think these articles are really talking about email applications (email clients) that are indeed quite obsolete (MS Outlook, Thunderbird, KMail, Yahoo Mail, take any of them …). Although you probably wont say that about GMail, on the contrary, it is quite refreshing – email threads presented almost as chats to encourage dialogs. I am actually very surprised that Google killed its project Wave which was taking GMail even further in the direction of email integrated with work place social environment.

Anyway, those are mostly email clients that are being blamed for their non-social implementations. And quite understandably, as most of them are >10yr old now. BUT the underlying email messaging system and infrastructure (as described by such protocols as RFC822, RFC2821 (smtp), RFC2045 (mime), RFC3501 (imap), …) are very solid, in my opinion. Many probably don’t realize that the whole web world has pretty much adopted MIME for content definitions, which was originally a standard for email message bodies. And what about the message transmission infrastructure, millions of SMTP servers across the Internet facilitating mail delivery, built to work around line failures and offline situations? I can’t believe we want to scratch all that.

As far as the email client apps go I definitely agree that they need to be updated and re-designed to accommodate new social collaboration needs, we are even building one app like that ourselves at Yoxel. But I am very intrigued with the question of the underlying infrastructure.  It is basically the question of “de-centralization” vs “centralization” . Do you like the idea of being locked in their cloud (Facebook, Twitter, Google, …) for all your messaging and collaboration needs or would you prefer a little more democracy and freedom where you continue to rely on the SMTP based Internet infrastructure not controlled by any one big company allowing a choice of alternative UI solutions (desktop and web-based)?

-Cheers

PS: For those who read the whole SF Gate article: It seems the Bugzilla bug-trackers I used in the past were a new generation social email apps because they sent email notifications inviting me to login and collaborate so I can easily say that they “layer enterprise social-networking on top of e-mail”. 🙂