The ESME to-do list

[David Pollak]

Folks,

ESME is very exciting.  Barely 6 months ago, it was a twinkle in the eye of a few energetic people and now it's a project that's known to tens of thousands, it's being incubated by the Apache foundation, and it's in active use at a number of global 100 companies.  Wow!

I believe that the ESME we see today is a mere glimpse of what ESME will become over the next 5 years.  I believe that mixing the current foundation and energy of the ESME community with a bunch of team-work, vision, and hard work, we can make ESME the definitive micro-communications platform, bar none.

There are a fair number of projects that need to be coordinated in order to keep ESME growing and evolving.  I'd like to list what I think the projects are and see if we can get some owners for the projects:

• Web-based User interface.  Create and manage a powerful, flexible web-based UI that has access to all the ESME features and can be customized easily.
• Flash/AIR-based User interface.  The same power of the web-based UI in a desktop application.
• The ESME REST-based API.  Manage and enhance ESME's REST API to support clients, support Twitter-API compatible clients, and allow interoperation with many other applications.
• Internal message routing.  This is one of the features that currently distinguishes ESME for just about every other messaging platform: the ability to define rules for managing messages.  I believe that this mechanism needs to become a full-fledged language and development system that does for information flow what HyperCard did for building end-user applications.
• Information pools and access control.  In order for ESME to grow and thrive in the enterprise, we need to define a powerful, understandable and usable mechanism for defining access control for messages and auditing for these mechanisms (who knew what, when?)
• Internal APIs and plugin mechanism.  ESME needs a way for external code to be plugged into it beyond what's available via REST.  This might include mechanisms for authentication/authorization, hooks into message routing and access control, etc.  I expect that the internal API/plugin mechanism will lead to commercial ESME plugins that will allow a commercial ecosystem to evolve around ESME.
• Attachments and search.  While I'm not personally keen on the concepts of attachments or searching for past messages, it's becoming clear that micromessaging systems are information repositories and must allow for retention and mining of information.
  
• Federation.  ESME instances do not exist in issolation.  They must interoperate with Twitter, the Open Microblogging architecture as well as interoperating with each other.  I have been working on a federation mechanism (along with information search and attachment distribution and caching) that is highly secure, cryptographically verifiable, etc.

Who would like to add items to the above list?

Who wants to volunteer to own particular items (I'd like to own federation and attachments/search and participate in access control, message routing, and internal APIs)?

Thanks,

David

PS -- I'm bcc'ing this message to a number of ESME-related mailing lists and people.  If you're interested in participating (or simply interested in watching ESME grow and evolve), please participate by subscribing to the esme...@incubator.apache.org mailing list.  For more information see http://incubator.apache.org/projects/esme.html


--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[Dennis Howlett]

@david: this is great stuff and I'm glad you've taken the effort to
put this together.

As you know, I have been fielding a few market calls from large
organizations so from that perspective I'm wondering whether we can
talk timestamped road maps and whether I can get more meat on what
each of these things mean for those wanting to use ESME.

Thanks

D -:)

--
This message is: private and confidential [ ] bloggable with prior
permisssion [ ] bloggable without permission [ ]
Dennis Howlett
t: +34 953 708 636 (int'll)
m: +34 607 482 739 (int'l)
skype: dahowlett

[Hirsch, Richard]

David.

Love that Hypercard reference - it dates us both as I was actually once a talented Hypercard developer.

Regarding the importance of internal plug-ins as a way to commercialize ESME, see this article ( http://is.gd/bL6e <http://is.gd/bL6e> ) in which there is a quote: CIOs "are happy to pay for proprietary extensions to open-source software"

Based on internal demands, an ability to create private / public groups is a critical feature. Would this be part of "Internal message routing" or "Information pools and access control"?

D.

________________________________

From: esme...@googlegroups.com on behalf of David Pollak
Sent: Mon 12/15/2008 19:22
To: esme...@incubator.apache.org
Subject: [ESME-dev] The ESME to-do list


Folks,

ESME is very exciting. Barely 6 months ago, it was a twinkle in the eye of a few energetic people and now it's a project that's known to tens of thousands, it's being incubated by the Apache foundation, and it's in active use at a number of global 100 companies. Wow!

I believe that the ESME we see today is a mere glimpse of what ESME will become over the next 5 years. I believe that mixing the current foundation and energy of the ESME community with a bunch of team-work, vision, and hard work, we can make ESME the definitive micro-communications platform, bar none.

There are a fair number of projects that need to be coordinated in order to keep ESME growing and evolving. I'd like to list what I think the projects are and see if we can get some owners for the projects:

* Web-based User interface. Create and manage a powerful, flexible web-based UI that has access to all the ESME features and can be customized easily.
* Flash/AIR-based User interface. The same power of the web-based UI in a desktop application.
* The ESME REST-based API. Manage and enhance ESME's REST API to support clients, support Twitter-API compatible clients, and allow interoperation with many other applications.
* Internal message routing. This is one of the features that currently distinguishes ESME for just about every other messaging platform: the ability to define rules for managing messages. I believe that this mechanism needs to become a full-fledged language and development system that does for information flow what HyperCard did for building end-user applications.
* Information pools and access control. In order for ESME to grow and thrive in the enterprise, we need to define a powerful, understandable and usable mechanism for defining access control for messages and auditing for these mechanisms (who knew what, when?)
* Internal APIs and plugin mechanism. ESME needs a way for external code to be plugged into it beyond what's available via REST. This might include mechanisms for authentication/authorization, hooks into message routing and access control, etc. I expect that the internal API/plugin mechanism will lead to commercial ESME plugins that will allow a commercial ecosystem to evolve around ESME.
* Attachments and search. While I'm not personally keen on the concepts of attachments or searching for past messages, it's becoming clear that micromessaging systems are information repositories and must allow for retention and mining of information.

* Federation. ESME instances do not exist in issolation. They must interoperate with Twitter, the Open Microblogging architecture as well as interoperating with each other. I have been working on a federation mechanism (along with information search and attachment distribution and caching) that is highly secure, cryptographically verifiable, etc.

Who would like to add items to the above list?

Who wants to volunteer to own particular items (I'd like to own federation and attachments/search and participate in access control, message routing, and internal APIs)?

Thanks,

David

PS -- I'm bcc'ing this message to a number of ESME-related mailing lists and people. If you're interested in participating (or simply interested in watching ESME grow and evolve), please participate by subscribing to the esme...@incubator.apache.org mailing list. For more information see http://incubator.apache.org/projects/esme.html


--

Lift, the simply functional web framework http://liftweb.net <http://liftweb.net/>
Collaborative Task Management http://much4.us <http://much4.us/>

[David Pollak]

On Mon, Dec 15, 2008 at 7:56 PM, Hirsch, Richard <richard...@siemens.com> wrote:

David.

Love that Hypercard reference - it dates us both as I was actually once a talented Hypercard developer.

Regarding the importance of internal plug-ins as a way to commercialize ESME, see this article ( http://is.gd/bL6e <http://is.gd/bL6e>  ) in which there is a quote: CIOs "are happy to pay for proprietary extensions to open-source software"

Based on internal demands, an ability to create private / public groups is a critical feature. Would this be part of "Internal message routing" or "Information pools and access control"?

The private/public stuff is information pools and access control.