Darren,
I fully agree with you. I have no plans to make ESME harder to use. At its
core, it's a micro-messaging system. On the other hand, I do want to make
it easier for people who are not Scala developers with access to the ESME
source code to build applications on top of ESME. I view this class of user
as similar to "Excel power users." But Excel power users often distribute
spreadsheets to their co-workers that allow the non-power-users to get
something new done.
Thanks,
David
On Wed, Aug 5, 2009 at 4:30 AM, dha...@fortybeans.com <dha...@fortybeans.com
> wrote:
> Yes, yes and yes. Maybe. ;-)
>
>
> I very much like the idea of having an elegant event-handling framework at
> the
> heart of ESME. However, it is also critically important that what we
> deliver to
> users does not require them to understand this.
>
>
> By analogy: Access is based on SQL and the whole set-theory thing. Most
> Access
> developers neither know nor care about this.
>
>
> In our case, we still need to deliver a *usable* micromessaging system -
> but if
> that system has a really powerful core that is accessible to power
> developers,
> then we have a huge opportunity.
>
>
> Remember: the business case is not "there is a really powerful engine
> here", but
> is more "you can use this to do X and Y more reliably, and less
> expensively,
> than any other alternative you may be considering".
>
>
> So with those caveats, I am very much in favour of the new approach. With
> suitable layering of code, API users and UI developers need not notice any
> significant differences.
>
>
> Cheers,
> Darren
>
> On 05 August 2009 at 01:04 David Pollak <feeder.of.the.be...@gmail.com>
> wrote:
>
> > Folks,
> >
> > First, I'm going to give a code example:
> >
> > *transform:*
> > tcw: (client) re: (what) [date] [timespan] => {type: 'tcw' client: client
> > topic: duration length: timespan when: date or update_time}
> >
> > *update:*
> > call log += {type: 'tcw'}
> >
> > What does this mean?
> >
> > The transformation is pattern matching an incoming ESME update against
> > anything that starts with the string "tcw:" followed by the name of a
> client
> > followed by the string "re:" followed by any text followed by an optional
> > date and timespan will get transformed to a JSON object and included as
> part
> > of the update.
> >
> > The second line appends the update to the "call log" table.
> >
> > These two lines allow you to create an ESME-based call log application.
> >
> > Second, "oh wow, relational databases are turtles all the way down."
> >
> > I've only taken 3 CS courses in my life... and nearly got thrown out of
> or
> > gotten flunked out of all of them (no one likes a smart ass). When I was
> in
> > law school, I took a database grad-level course. I thought it'd be an
> easy
> > grade given that I'd written a moderately successful commercial flat file
> > database. It was a mind-blower that relational databases were (1) based
> on
> > real math (set theory) and (2) that the database schema was defined by
> data
> > in a set of tables.
> >
> > Over the years, I've been constantly reminded of the simple purity of
> > relational databases. They are meta-defined. They are logs and
> snapshots.
> > They are immensely fast and powerful embodiments of math... not the
> > messy/sloppy stuff of imperative programs.
> >
> > Stick with me... there's a little more free association here... but there
> is
> > a point that I hope will be wrapped up in a nice bow.
> >
> > Third, Twitter, VisiCalc, and DBase 2 (which is still better than a bilge
> > pump <http://en.wikipedia.org/wiki/Ashton-Tate#Trivia>) were all, IMHO,
> > groundbreaking applications. Each one of them was dead simple to use and
> at
> > their core embrace composition. Many small (and even medium sized)
> > businesses are powered by Excel and FileMaker and/or Access (the linear
> > successors). All of the applications that have grown up around the 140
> > character messages demonstrate the power of a line of text. VisiCalc
> > (improved by 1-2-3, Excel, Mesa <http://www.plsys.co.uk/mesa.htm> and
> others
> > and brilliantly re-conceived by Improv) demonstrated the compositional
> power
> > of programming by relating data cells to one another. "Normal people"
> can
> > use FileMaker/Access to write a whole lot of powerful applications. We
> can
> > throw in some other marginal (but cool) apps including
> > SBook<http://simson.net/ref/sbook5/>.
> > These apps are high on "making sense of unstructured data" scale... which
> I
> > believe is critical to usability.
> >
> > Fourth, ESME's "actions" are a huge differentiator. They embody a lot of
> > what external apps do with Twitter and put the same functionality (it's
> > pretty hard coded) into ESME directly. Vassil's excellent (and
> dangerous)
> > suggestion of allowing Scala scripts to be actions triggered by matching
> > updates was a great idea. Further, Vassil (okay, this is all Vassil's
> > fault) had the great idea of putting updates relating to user
> > change/add/login/etc. into the user's timeline. All this stuff drives at
> > (1) allowing users a ton of flexibility in behavior makes ESME different
> > already and (2) everything should be an event.
> >
> > But... what if we took the theoretical underpinnings of "everything is an
> > event" and merged it with pattern matching event "annotation" so that we
> can
> > process events as they are sent (and as they arrive in our mailbox) and
> then
> > modify tabular data structures based on matching the events and the event
> > contents. Formulas can be triggered based on the new calculations and
> > trigger the creation of new updates and/or perform external actions. But
> > everything, I mean everything including system start-up, user creation,
> etc.
> > is all event based. That means we've got a Twitter/VisiCalc/DBase thingy
> > that might be powerful and flexible because it allows business people to
> > manage complex data stream in simple, composable (and debuggable) ways.
> >
> > An event-driven ESME with appropriately easy/powerful pattern matching
> and
> > data structure definition/mutation will, I believe, bring a lot of the
> power
> > of VisiCalc/1-2-3/Excel and FileMaker/Access to the networked world.
> People
> > can write (or share) applications for time billing, project management,
> to
> > do lists, calendaring, etc. But the front end is not part of the app...
> a
> > web page can post to a REST interface that will result in an event being
> > generated (think about the power of the forms-based front end to Google
> > spreadsheets). The back end is not part of the app... events are just
> made
> > available to other services, UIs, etc.
> >
> > So, there's non-trivial work in terms of defining grammars for end users
> and
> > building a system that is a meta self-hosted system (because if
> everything
> > is an event, then users must be data structures stored just as any other
> > user-defined data structure... turtles all the way down.) On the other
> > hand, once defined, it's a system that invites broader participation is
> > "coding" because it's stuff that anyone who writes Excel formulas can
> > contribute to.
> >
> > I think that on the 1 year anniversary (today is the 1 year anniversary
> give
> > or take a week of my participation on ESME and the registration of
> esme.us),
> > we should explore what we could make of ESME.
> >
> > Personally, I have not found a business model around putting social
> > messaging behind the firewall. However, I see a very nice business in an
> > ESME hub (that can bridge between federated behind the firewall ESME
> > instances) that also provides "applications" built on top of the
> platform.
> > This provides a nice incentive for me to spend a lot of time making ESME
> G2
> > into something viable. Further, we've seen a lot of problems baked into
> the
> > "hurry up and get it out" current version of ESME including a very
> brittle
> > User class, UI that's part of the core Scala code, etc. Also, ESME has
> been
> > very XML oriented... I've been leaning a lot more towards JSON as data
> > format.
> >
> > So... am I smoking crack or does the concept of G2 sound reasonable? If
> it
> > does sound reasonable and I could get something running by mid September,
> > what do you folks think of putting ESME resources into G2? If some of
> you
> > are on the fence, what questions do you have to push you to one side of
> the
> > fence or the other?
> >
> > Thanks,
> >
> > David
> >
> > PS -- I've bcc'ed a couple of folks that I'm trying to lure into the ESME
> G2
> > project
> > PPS -- I told Dick I'd run this email by him before sending it to the
> > list... I didn't do that and I hope it does not catch him too unaware...
> > especially coming back from vacation and all.
> >
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Git some: http://github.com/dpp
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
