You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Steve Lee <sl...@opendirective.com> on 2011/10/05 20:01:50 UTC
Supplying server support files for widgets
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
Re: Supplying server support files for widgets
Posted by Scott Wilson <sc...@gmail.com>.
On 5 Oct 2011, at 20:15, Steve Lee wrote:
> On Wed, Oct 5, 2011 at 7:47 PM, Scott Wilson
> <sc...@gmail.com> 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
Re: Supplying server support files for widgets
Posted by Steve Lee <st...@fullmeasure.co.uk>.
Actually could this also work?
3) Expect server side requirements (e.g PHP) to be installed alongside
Wookie server.
Or do URIs get mangled such that it won't without some manual or auto fixup?
Steve
On Wed, Oct 5, 2011 at 8:15 PM, Steve Lee <st...@fullmeasure.co.uk> wrote:
> On Wed, Oct 5, 2011 at 7:47 PM, Scott Wilson
> <sc...@gmail.com> 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?
>
> 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
>
Re: Supplying server support files for widgets
Posted by Steve Lee <st...@fullmeasure.co.uk>.
On Wed, Oct 5, 2011 at 7:47 PM, Scott Wilson
<sc...@gmail.com> 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?
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
Re: Supplying server support files for widgets
Posted by Scott Wilson <sc...@gmail.com>.
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" <sl...@opendirective.com> 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
Re:Supplying server support files for widgets
Posted by Ross Gardler <rg...@opendirective.com>.
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" <sl...@opendirective.com> 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