esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <>
Subject Re: Turtles all the way down (or how I learned to love math in computing)
Date Mon, 17 Aug 2009 16:12:11 GMT
On Mon, Aug 17, 2009 at 1:46 AM, Anne Kathrine Petter√łe

> I was more just wondering if David would need some help from the rest of
> us?

What I've done so far is to create a project at GitHub ( )  I find Git's branching much
easier to allow for playing and exploring... which will be very important in
the early days.  I will add all the ESME committers to the GitHub project.
Once the codebase stabilizes, we can move it into the Apache repo.  (If the
Apache powers that be have an issue with this, let's all talk through it

I think we do need to get to a release of ESME which includes (1) a stable
UI and (2) a flexible authentication system (OpenID, User/pwd, etc.)  We
need a stake in the ground that says, "we can ship."

Right now, I've been down in Goat <>
(which, along with Lift, will provide the foundation for G2).  My goal
is to allow the description of G2 with something like (not pseudo code, but
actual Scala code):

ReceiveUpdate[(User, JSON), (User, Update)] %> ApplyInterpretations[(User,
Update), (User, Update)] %> (DistributeTo[(User, Update), (User, User,
Update)] * PostToInbox[(User, User, Update), Unit])

This will allow for a high level description of the message flow process.
The message flow (inline, Actor-based, distributed) and logic lookup (think
Erlang-style run-time changes to business logic) is handed by the runtime
and does not impact the definition of the business logic.

I've got some good stuff running on my local machine (there's one set of
code that I can't check into the Goat Rodeo repository until I get sign-off
from the author, so this stuff is local to me.)

So, what would be great from the ESME team are:

   - A list of external sources and sinks of ESME updates.  The list
   includes: Twitter, iCal, generic RSS.  I have no idea of where we want to
   send (sink) ESME updates.  In the above update flow, the sources would hook
   to ReceiveUpdate.  PostToInbox will result in something other than Unit...
   and that would be an attachment point for sinks.
   - A list of apps you'd like to build on top of ESME.  My list includes:
   To Do (on a pool-by pool basis, so it could be a work-group to-do app),
   hours tracking on a project by project basis.  Once you have the app in
   mind, think about example input (updates) that would drive the app, think
   about a tabular data structure for representing the data required for the
   app, and how the updates mutate the data table(s) (can this be expressed
   with a simple spreadsheet-like formula?)

I hope to formalize the above into (1) coding tasks to write the simple
bridges between the sources/sinks and the core system and (2) integration
tests for the application/example code/documentation for end users.

Sound reasonable?



PS -- I'm off ESME today, but back on for most of the rest of the week.

> /Anne
> On 17. aug.. 2009, at 10.37, Richard Hirsch wrote:
>  As I said in a previous email,  I'm assuming that a branch would be
>> easiest way for @dpp to get started.
>> D.
>> On Sun, Aug 16, 2009 at 10:20 PM, Anne Kathrine
>> Petter√łe<> wrote:
>>> David,
>>> I would say we have all agreed that G2 is the way forward.
>>> How you thought about how we proceed from here? Who does what?
>>> /Anne
>>> On 12. aug.. 2009, at 09.15, Vassil Dichev wrote:
>>>  Actually, I think this is an extension to microblogging.
>>>>> If I microblog:
>>>>> tcw: dickh re: #ESME standup time: 30min
>>>>> todo: add different authentication to #ESME
>>>>> working on: #ESME authentication
>>>>> done: #esme authentication
>>>>> over the course of a day, those updates are meaningful to humans, but
>>>>> can
>>>>> also be parsed and used to update structured data.
>>>> In fact, the idea is not new. Take a look at :
>>>> "...simple, open, semi-structured format for embedding
>>>> machine-readable, yet human-friendly, data in Twitter messages...".
>>>> That totally defines what we want to do with actions.
>>>> Granted, you won't see as much interest in processing messages on
>>>> Twitter as in a corporate environment, but @rtm, @timer and
>>>> @iwantsandy are still quite popular.
>>>> I also don't see this as something that replaces what ESME currently
>>>> is, but as a way to extend ESME. Most likely the change wouldn't even
>>>> be noticeable, like when Google introduced Calculator- there's no
>>>> change in the interface, but if you typed "2+2" or "123 in hex" or
>>>> "sin(pi/4) ^ 2", the result would get evaluated.
>>>> Vassil

Lift, the simply functional web framework
Beginning Scala
Follow me:
Git some:

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