On 5 Oct 2011, at 20:15, Steve Lee wrote: > On Wed, Oct 5, 2011 at 7:47 PM, Scott Wilson > <[email protected]> wrote: >> There is a similar use case as part of the Omelette project [1]. I've CC'd >> Samuel who can maybe say more about it, but basically in this case there is >> an authoring tool, MyCocktail [2] that creates mashups consisting of both >> the client-side widget, and some server-side mashup logic. >> >> The options are to: >> >> 1. Produce a Widget package that also has some server-side code in it that >> Wookie would then have to unpack and dispatch to another application server >> 2. Produce a Widget package and also a server-side mashup package as >> separate bundles, the widget goes to Wookie and the server bundle goes to >> the application server, and we use some service discovery to link them up >> >> The current thinking is to lean towards option 2, with the server-side >> package being a Node.js [3] or similar server-side JavaScript application, >> but I think we'll find out more once we make more progress on implementation. >> >> Is this similar to what you're after, Steve? > > Yes pretty much. I was thinking of 1 and wookie widget build could > strip out the server stuff. Of course even with manual deployment of > server side elsewhere, the URL references in the widget will need > fixing up. > > Option 2 sounds good. What service discovery standards could be easily > used on both sides?
Well, the thing is that the concrete service URL may be dynamically generated, so you can't hard code the connection. So we would use a service registry, perhaps using the widget URI as the identifier for looking it up using a lazy loading script, e.g.: http://iecbolton.jira.com/source/browse/OM/loader/trunk > > In my case the server side support is trivial [1] and I'm guessing > that it might be possible to assume JSP or some such on the wookie > server and use that? The advantage of PHP is easy stand-alone text > using XAMPP etc. Perhaps there is similar for java tech? Just thought, > perhaps server side includes would do the trick - it ages since I uses > that old tech so I can't recall it's limits > > 1: http://git.opendirective.com/p/ipo/source/tree/master/server/actions.php Well, in Widget land I guess this is what <feature> is for. This can do server-side stuff (e.g. the Wave one does) but we've stripped that out to make it much easier to deploy them. Maybe we could add it back in, but in a way that doesn't get us into a mess with classloaders and reflection? I quite like the idea of using server-side JavaScript for this (e.g. RingoJS, Rhino), especially if the server-side coding is pretty limited. The solution outlined above I think assumes some quite signifiant backend logic or service access rather than just a script. S
