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? S [1] http://www.ict-omelette.eu/home [2] http://www.ict-romulus.eu/web/mycocktail [3] http://nodejs.org/ On 5 Oct 2011, at 19:19, Ross Gardler wrote: > Can you explain you're use case. Widgets are a client side technology and > thus don't carry "server side support". Without understanding the use case > is hard to suggest a solution. > > Sent from my mobile device, please forgive errors and brevity. > On Oct 5, 2011 7:16 PM, "Steve Lee" <[email protected]> wrote: >> Is there any standard way of packaging server side support files (e.g >> PHP) in widget tarballs and widgets themselves? >> >> I've stuck mine in a 'server' folder and the widget client code >> references it there. >> >> Steve Lee >> Programme Leader (Open Accessibility) >> OpenDirective http://opendirective.com
