[PROPOSAL] ESME - The Enterprise Social Messaging Experiment
Darren Hague
Enterprise Social Messaging Experiment (ESME) is a secure and highly
scalable microsharing and micromessaging platform that allows people to
discover and meet one another and get controlled access to other sources
of information, all in a business process context. ESME is written in
Scala and uses the Lift web framework.
Please see http://wiki.apache.org/incubator/ESMEProposal for details.
Since this is my first Apache project, any and all feedback is welcome -
I will call for a vote a few days after relevant messages on the list
reduce to a trickle and people seem happy with the proposal.
Best regards,
Darren Hague
David Pollak
On Tuesday 04 November 2008 9:23:19 am J Aaron Farr wrote:
> Darren Hague <dha...@fortybeans.com> writes:
> > I would like to propose ESME as a project for the Apache Incubator.
> >
> > Enterprise Social Messaging Experiment (ESME) is a secure and highly
> > scalable microsharing and micromessaging platform that allows people
> > to discover and meet one another and get controlled access to other
> > sources of information, all in a business process context. ESME is
> > written in Scala and uses the Lift web framework.
> >
> > Please see http://wiki.apache.org/incubator/ESMEProposal for details.
> >
> > Since this is my first Apache project, any and all feedback is welcome
>
> Welcome!
>
> Just want to add that I've volunteered to Champion and mentor this
> project. We're still looking for other mentors.
While not something that falls into my normal spheres of influence, I'll
happily throw my name into the mentor mix if needed mostly due to prior (very
positive) experience working with Dave. I'm more than happy to help out.
Who knows... maybe I'll learn a bit about Scala/Lift in the process.... :-)
Yep... all part of my master plan to lure Dan into learning Lift and Scala. ;-)
Dan
> > I will call for a vote a few days after relevant messages on the list
> > reduce to a trickle and people seem happy with the proposal.
>
> With ApacheCon this week, we'll want to give this a little extra time.
> I'd wait to hold a vote until next week at the earliest.
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-u...@incubator.apache.org
For additional commands, e-mail: genera...@incubator.apache.org
--
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
Darren Hague
None of us are at ApacheCon, unfortunately - maybe a few of us will be at ApacheCon Europe...
I am based in the UK, and happy to chat at any time that suits both our timezones.
Cheers,
Darren
>On Mon, Nov 3, 2008 at 5:22 PM, Darren Hague <dha...@fortybeans.com> wrote:
>> ...I would like to propose ESME as a project for the Apache Incubator...
>
>Sounds interesting! I'm willing to help as a mentor.
>
>Are any of you guys at ApacheCon by any chance? If yes let us know so
>we can have a chat.
>
>-Bertrand
Dennis Howlett
You 'can' regard ESME as a 'Twitter for Enterprise' but we prefer not
to do so because we then get tangled in all sorts of arguments and
comparisons that deflect from how we see the service.
The premise upon which we started this project was that Twitter style
services are generic and have no intrinsic purpose other than to
provide a flow of data. We wanted to provide context and purpose
because that is what enterprise understands.
In our early demo iterations, we therefore positioned this as a tool
that helps both the discovery of the *right* people within distributed
networks who can help solve problems, lend advice or point in the
direction of others in a 'behind the firewall' setting.
We created use cases to support that idea using SAP specific business
processes and then showing different ways of using the tool with
different clients such as web and WebDynpro (SAP specific).
I invite you to visit the blog: http://blog.esme.us (it MAY be
slightly flaky as we've just moved servers and it hasn't been fully
tested) where team members have posted a variety of information on use
cases, client side code examples etc.
Hope that helps.
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
Dennis Howlett
handful of folk in their immediate 'network' which can provide a
starting point. Tags is one method of discovery as are 'words' used in
messages.
FYI - there is a design discussion underway re: the current client.
D -:)
On Wed, Nov 5, 2008 at 3:42 AM, Sanjiva Weerawarana
<san...@opensource.lk> wrote:
> (FYI this conversation has no impact on the acceptance or not of the
> proposal .. just my curiosity. So if you feel there's a better place for
> this conversation please point me there.)
>
> When you say its really a tool to discover right people can you elaborate on
> what that means? Is there some protocol or do you tag yourself with stuff
> and then others discover you or ??
>
> I did visit the site and log in with my OpenID but that didn't make any more
> sense; looks like the twitterfox client I use :).
>
> Thanks,
>
> Sanjiva.
>
> Dennis Howlett wrote:
>>
>> @sanjiva - I'll field this as the 'positioning' guy.
>>
>> You 'can' regard ESME as a 'Twitter for Enterprise' but we prefer not
>> to do so because we then get tangled in all sorts of arguments and
>> comparisons that deflect from how we see the service.
>>
>> The premise upon which we started this project was that Twitter style
>> services are generic and have no intrinsic purpose other than to
>> provide a flow of data. We wanted to provide context and purpose
>> because that is what enterprise understands.
>>
>> In our early demo iterations, we therefore positioned this as a tool
>> that helps both the discovery of the *right* people within distributed
>> networks who can help solve problems, lend advice or point in the
>> direction of others in a 'behind the firewall' setting.
>>
>> We created use cases to support that idea using SAP specific business
>> processes and then showing different ways of using the tool with
>> different clients such as web and WebDynpro (SAP specific).
>>
>> I invite you to visit the blog: http://blog.esme.us (it MAY be
>> slightly flaky as we've just moved servers and it hasn't been fully
>> tested) where team members have posted a variety of information on use
>> cases, client side code examples etc.
>>
>> Hope that helps.
>>
>> Thanks
>>
>> D -:)
>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> Blog: http://sanjiva.weerawarana.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-u...@incubator.apache.org
> For additional commands, e-mail: genera...@incubator.apache.org
>
>
--
Mrinal Wadhwa
>> Is there any wire protocol standard involved with this?
Right now its all HTTP .. we use long polling (Comet) to make the message delivery almost instant
>> is there any way to make this interop with twitter? Does twitter have a server-server communication / federation model too like XMPP?
Vassil has done some work in this area but from what I understand it's based on the twitter API and not something more powerful
>> When you say its really a tool to discover right people can you elaborate on what that means?
>> Is there some protocol or do you tag yourself with stuff and then others discover you or ?
_
Mrinal
http://weblog.mrinalwadhwa.com
David Pollak
Hi Sanjiva,Right now its all HTTP .. we use long polling (Comet) to make the message delivery almost instant
>> Is there any wire protocol standard involved with this?Vassil has done some work in this area but from what I understand it's based on the twitter API and not something more powerful
>> is there any way to make this interop with twitter? Does twitter have a server-server communication / federation model too like XMPP?
I'm working on a secure protocol for inter-server federation. It's based on another project I'm running called Social Material. Administrators will be able to white/black list different servers. All server validation will be done with SSL certs. Each message will be signed by the user who sent the message. Each message will be encrypted based on sender and target server such that messages can be cached by intermediate servers, but they cannot read the message. I'm expecting that server-to-server IPC will be over HTTP/HTTPS, but it's not manditory.
David Pollak
Darren Hague wrote:
I would like to propose ESME as a project for the Apache Incubator.
Enterprise Social Messaging Experiment (ESME) is a secure and highly scalable microsharing and micromessaging platform that allows people to discover and meet one another and get controlled access to other sources of information, all in a business process context. ESME is written in Scala and uses the Lift web framework.
I've been looking at Scala and Lift while I was searching ways to apply Erlang's lightweight process approach to Java. So this is a very cool proposal and I'm willing to help as a mentor, so that it can finally force me to get my hands dirty on Scala!
However, this proposal could be made way more interesting and potentially disrupting if it were to include the Lift framework itself, and also consider not only enterprise micro-blogging, but also open federated microblogging [1] that was initiated by Identi.ca [2].
Speaking for Lift (I'm the BDFL of Lift), I'm very very happy with how we've been hosting Lift. I don't see a compelling reason to move Lift to the Apache foundation.
ESME will support a variety of standard-ish APIs including Twitter's APIs, open federated micro blogging APIs, etc. It will also have a set of secure federation APIs.
Micro blogging has become part of the daily activity of many people, and a scalable open source solution to run federated microblogging would be really nice, rather than wondering when will be Twitter's next downtime ;-)
Sylvain
[1] http://openmicroblogging.org/
[2] http://identi.ca/
--
Sylvain Wallez - http://bluxte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: general-u...@incubator.apache.org
For additional commands, e-mail: genera...@incubator.apache.org
--
Darren Hague
One of the value-added aspects of ESME is in the server-side logic, which allows users to set up rules & behaviours (e.g. "only send me messages from X if they are tagged Y", and "email me when someone starts following me"). Also, there is a fundamental difference in attitude between broadcast & subscribe: XMPP/Jabber and email are used to send messages *to* people; ESME and other microsharing solutions are more about end users deciding who they want to hear *from*. Having said that, there is a sense in which we are somewhere in the middle of a continuum that has email at one end and IM at another. Even so, we think we occupy a niche with strong demand, especially for enterprise-grade levels of security and control over messaging - none of which is present in IM or email solutions.
Please have a read through the articles at http://blog.esme.us/ for more about what makes us different & valuable.
Best regards,
Darren
>Hi.
>
>don't take this the wrong way, but what is wrong with XMPP and jabber
>for this kind of thing? wouldn't it make more sense to just extend that?
>
>
>
>Darren Hague wrote:
>> I would like to propose ESME as a project for the Apache Incubator.
>>
>> Enterprise Social Messaging Experiment (ESME) is a secure and highly
>> scalable microsharing and micromessaging platform that allows people
>> to discover and meet one another and get controlled access to other
>> sources of information, all in a business process context. ESME is
>> written in Scala and uses the Lift web framework.
>>
>> Please see http://wiki.apache.org/incubator/ESMEProposal for details.
>>
>> Since this is my first Apache project, any and all feedback is welcome
>> - I will call for a vote a few days after relevant messages on the
>> list reduce to a trickle and people seem happy with the proposal.
>>
>> Best regards,
>> Darren Hague
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-u...@incubator.apache.org
>> For additional commands, e-mail: genera...@incubator.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-u...@incubator.apache.org
>For additional commands, e-mail: genera...@incubator.apache.org
>
David Pollak
Hi Ian,
One of the value-added aspects of ESME is in the server-side logic, which allows users to set up rules & behaviours (e.g. "only send me messages from X if they are tagged Y", and "email me when someone starts following me"). Also, there is a fundamental difference in attitude between broadcast & subscribe: XMPP/Jabber and email are used to send messages *to* people; ESME and other microsharing solutions are more about end users deciding who they want to hear *from*. Having said that, there is a sense in which we are somewhere in the middle of a continuum that has email at one end and IM at another. Even so, we think we occupy a niche with strong demand, especially for enterprise-grade levels of security and control over messaging - none of which is present in IM or email solutions.
Please have a read through the articles at http://blog.esme.us/ for more about what makes us different & valuable.
In addition, the choice of transport (HTTP or XMPP) does not speak to the format of the enclosed message. There is a lot of specific stuff in the communication protocol. The format of the message (signing, encryption, etc.) is the thing of value, not the way the bytes are moved.
In terms of actual implementations of HTTP and XMPP, I lean towards HTTP for a number of reasons:
- There is only one reasonable open source XMPP implementation for the JVM: OpenFire. OpenFire in my experience has a ton of bugs. On the other hand, there are a number of good client and server packages for HTTP.
- ESME instances will already be running on an HTTP port. Adding an XMPP port to the mix as a requirement for federation means opening yet more ports in firewalls. This is a non-trivial administrative burden.
Thanks,
David