I like the idea of making ESME more available for other types of applications. One application core with micro-blogging being one example of an app that is based on the core.
But (and there is always a "but") - don't you you think you are moving more towards ESME being a message-broker / service bus. If this is intended, what then are the distinguishing characteristics regarding other existing message brokers. My other qustion would be: what remains of the existing application? Could we save anything or must be start anew (groan) again. D. On Mon, Aug 10, 2009 at 11:09 PM, Anne Kathrine Petterøe<[email protected]> wrote: > David, > > Sorry for the late and short reply. You have already said most of what I > wanted to say by now :) > I think we should definitely go for it. > > I am still wondering if we should still keep the "old" ESME too? > Or will it be an either or situation? > > And regarding this: > " I could conceivably refocus on G2 (but I do want to know more details) and > let the UI masters work their magic." > -- at the moment we don't have any UI masters on the team, which is turning > into a *serious* problem. > Anyone know a UI developer with free time on his hands? > > /Anne > > > On 5. aug.. 2009, at 17.27, David Pollak wrote: > >> On Wed, Aug 5, 2009 at 7:57 AM, Vassil Dichev <[email protected]> wrote: >> >>>> 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. >>> >>> If it's too complicated, there could be a plugin/version "extra >>> actions" the way there are separate formula packages for Excel. >> >> >> Yeah... there has to be layered template libraries available to the power >> users. This is part of the business model that I'm thinking about... >> basically... an eco-system (marketplace, app store) for composable >> elements. >> >> >>> >>> >>> For complex tasks like this, tooling matters. It should be easy to >>> compose/debug. >> >> >> Yes. I've been thinking about "play this range of updates" or >> "single-step >> this range of updates" so you can see what would happen if you applied >> certain transformations/accumulations. >> >> >>> ESME has some similarities to Yahoo!Pipes- both reroute >>> and transform pieces of text, but in a different context. However, >>> Yahoo!Pipes makes it easy to assemble components graphically like Lego >>> pieces, thereby ensuring that inappropriate pieces don't fit together. >> >> >> Yep. Yahoo! Pipes is a great visual builder... but it also feels very >> "push" rather than "reach into the ether and find what I'm looking for." >> >> >>> >>> >>> Vassil >>> >> >> >> >> -- >> 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 > >
