OK. I like the idea of G2 and also the idea of re-using as much existing code as possible.
Probably be easiest to just create a branch and go for it. That way you don't have to wait for a vote on the list and can start coding immediately. Once the branch is stable, we can vote on moving it to the trunk. D. BTW: I'm hoping that your imaginary message "done: #esme authentication" is true :-> D. On Tue, Aug 11, 2009 at 7:52 PM, David Pollak<[email protected]> wrote: > On Tue, Aug 11, 2009 at 5:08 AM, Richard Hirsch <[email protected]>wrote: > >> 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. > > > 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. > > If you can reply to the todo: message with "watch: I care about this > feature", that might trigger heightening the visibility of updates from this > to-do item. > > So, I think that the "turtles" direction remains pure and true to > microblogging, but allows people to build (and maybe share) applications > built on the semi-structured data. > > >> >> >> 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. > > > I personally think every line of code I've written should be burned down > (but I always have a low opinion of the re-use of my code.) I will make > sure to use as much of Vassil and others' code as I can. Also, I'm going to > try to preserve the stuff that's UI related. > > Thanks, > > David > > >> >> >> 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 >> > >> > >> > > > > -- > 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 >
