incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Pollak" <feeder.of.the.be...@gmail.com>
Subject The ESME to-do list
Date Mon, 15 Dec 2008 18:22:36 GMT
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-dev@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message