On 16 May 2011, at 16:46, Lucas Anastasiou wrote: > Hello Scott, Ross and the rest of wookie development team, > > I 've seen that Thomas replied giving some info regarding the elgg > plugin and I will try to share with the rest of the community what we > have done -or plan to do- regarding wookie development. > > We are currently developing a widget store that it is based in the > wookie engine. This will include users accounts, tagging, commenting, > rating, each widget to have its own "profile" page etc. .
This is a really interesting area, and is something we want to pursue in ITEC too. Ross suggested having a Wookie sub-project just for a widget store implementation with these features. Would that be of interest? > A lot of > alterations are made but apart from GUI (and store)-oriented work what > can be considered as "extensions" on wookie engine is: > > 1. Assign an API key to a collection of widgets. This allows an API > key to access only selected widgets implementing in that sense a > trivial access control but also allowing an external site > administrator to easily monitor and control what widgets his site > should access. Sounds like a good addition; so basically the Wookie admin can put some widgets off-limits for some API keys, e.g. if there are licensing or content-rating restrictions.? > 2. Usage monitoring: Since we are really interested -in the future- to > be able to track which widgets are used together, a logging mechanism > to store -in a persistent manner- widget instantiations requests. This > also enables us to display some usage statistics on each widget page > (and from that later deduce popular widgets so we can feature them , > ...) Presumably if we separated out Wookie and the Widget Store, we could expose usage information via an API? I suspect there is probably a way to hook this into commons-logging/log4j. > 3. Inter-widget communication dependency modelling: inter-widget > communication is enabled - we used as a basis the version of wookie > which was developed for LTfLL project (an early copy of this mod can > be found here: http://sourceforge.net/projects/ltfll/files/wookie-iwc/ > ). A widget author can include on the config.xml file a dependency > feature that basically declares from what other widgets the current > widget is required and what other widgets are required to load on the > same web-page in order to operate in the expected way. Something like: > <feature name="http://widgets.kmi.open.ac.uk/wookie/dependency"; > required="true"> > <param name="widget x" value="isRequired"></param> > <param name="widget y" value="requires"></param> > </feature> > (which is still w3c compliant since we treat dependency as a feature) > This feature injects css/javascript files which are used as a > inter-widget communication coordinator and as a framework for deployed > widgets to track what other widgets are loaded on the same web-context > and give the end users some notification (this is currently on > development phase - any suggestion of how to use these js code is more > than welcome). At the moment all we do is to display on each widget's > page what other widgets are required/requires to function correctly. Have you had a look at the new Feature packaging and loading mechanism? Would this work for deploying your solution? http://wookie.staging.apache.org/wookie/docs/developer/features.html If so, you should submit it - so long as there are no license issues - and we can add it to the "scratchpad" area. > All of the above are only implemented for JPA/mySQL (no JCR, not > tested for other db engines). Everything is really in alpha (not even > beta) phase but we would love to share our code with the rest of the > community. All extra code is included in Wookie packaging - we did not > hold app-store code separated from the rest of the wookie core (that > means that we massively altered the database schema - I think you will > not appreciate this approach) . But given there are several other projects wanting to do some sort of app store, I think porting the general concepts into a sub-project shouldn't be too hard. It might also bring other benefits from being built for that concern rather than having to fit in with the constraints of how Wookie is built. I know our team would want to contribute as we need to deliver that kind of functionality for ITEC. > > I really enjoyed our talk during your visit at the Open University > last week and the above summarises what we already discussed; just > recording them to share with the rest of the community. > Really looking forward for any suggestions/feedback > > Best regards, > > Lucas > > > > > On Mon, May 16, 2011 at 2:10 PM, Thomas Ullmann <[email protected]> wrote: >> Hello Scott and Ross, >> >> Was great talking to you the other day at the Open University. >> Indeed we created an Elgg plugin for the Elgg 1.7.x versions, using >> the PHP connector framework >> (http://svn.apache.org/repos/asf/incubator/wookie/trunk/connector/). >> It is basically a complete rewrite of the plugin developed by Bernhard >> (http://community.elgg.org/pg/plugins/hoisl/read/385029/wookie-widgets). >> >> It contains for example a search interface for widget, an easier way >> to select widgets, port filtering mechanism (for example in a setup >> with an apache forwarding the request to the tomcat server to wookie >> on port 8080, it filters the response containing 8080 so that the next >> request will be on port 80 again; this was an issue, because some >> institutions block port 8080 and thus the widgets were not available >> for them), and uses the connector framework. >> >> We are currently cleaning it up and documenting it a bit more to get >> it ready for publishing on the Elgg community side >> (http://community.elgg.org/pg/plugins/all/) within the next two weeks. >> However you can already have a look at it. Go to >> http://www.teleurope.eu and create an account there. You can then >> instantiate Wookie widgets on your dashboard or profile page. I also >> managed to make Wookie widgets available on the landing page (Elgg >> custom index widget plugin). See for example the Podcast player widget >> or the BuRST Search widget (both developed by Lucas). >> Regarding the enhancements: >> >> Take also a look at the EventSpace of TELeurope. This is a plugin for >> Elgg allowing widgets to have more space on an Elgg page (I will >> release this as well on the Elgg community page), compared to the >> three column layout on the Elgg dahsboard and profile page. >> >> To make the connector framework work, it just needed a slight >> modification to get the descriptions of the widgets (as far as I >> remember), but nothing major. @Ross: However, I am curious what you >> meant with not fully functional. >> >> Thomas >> >> >>> ---------- Forwarded message ---------- >>> From: Scott Wilson <[email protected]> >>> To: wookie-dev <[email protected]> >>> Date: Thu, 12 May 2011 15:32:58 +0100 >>> Subject: Wookie at the UK Open University; White-label app stores >>> Just a quick note to say I visited the Knowledge Media Institute (KMI) at >>> the Open University earlier this week to record a lecture, and also had an >>> opportunity to spend some time talking Wookie development with Thomas and >>> Lukas, who have done some interesting stuff with Wookie for their projects >>> involving LSA and all kinds of other goodies, including an enhanced Elgg >>> plugin using the PHP connector framework. >>> >>> Anyway, I know they are both reading this so hope they can share with the >>> community some of the extensions they've made to Wookie :-) >>> >>> While I was there we also had chance to talk about the whole area of widget >>> stores: things like searching, tagging, reviews and ratings. We've mostly >>> kept away from that kind of functionality within the Wookie core (except >>> for services, which are basically tags, and which don't feel quite right), >>> but its come up in several places now. >>> >>> Should we look at developing a "white label app store" over the top of (one >>> or more) Wookie/Shindig servers as a separate project? Or would it fit >>> better in Rave? >>> >>> S >>> >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Ross Gardler <[email protected]> >>> To: [email protected] >>> Date: Thu, 12 May 2011 15:55:24 +0100 >>> Subject: Re: Wookie at the UK Open University; White-label app stores >>> On 12/05/2011 15:32, Scott Wilson wrote: >>>> >>>> Just a quick note to say I visited the Knowledge Media Institute >>>> (KMI) at the Open University earlier this week to record a lecture, >>>> and also had an opportunity to spend some time talking Wookie >>>> development with Thomas and Lukas, who have done some interesting >>>> stuff with Wookie for their projects involving LSA and all kinds of >>>> other goodies, including an enhanced Elgg plugin using the PHP >>>> connector framework. >>> >>> Where is the code for this? I just moved the connector documentation across >>> to the new CMS, I'd like to make sure we are linking to this "enhanced Elgg >>> plugin". >>> >>> Furthermore, in what way is it enhanced? The PHP connector is not fully >>> functional, are there any enhancements to our framework code? If so can we >>> have it please? >>> >>>> Anyway, I know they are both reading this so hope they can share with >>>> the community some of the extensions they've made to Wookie :-) >>> >>> Please, pretty please ;-) >>> >>>> While I was there we also had chance to talk about the whole area of >>>> widget stores: things like searching, tagging, reviews and ratings. >>>> We've mostly kept away from that kind of functionality within the >>>> Wookie core (except for services, which are basically tags, and which >>>> don't feel quite right), but its come up in several places now. >>>> >>>> Should we look at developing a "white label app store" over the top >>>> of (one or more) Wookie/Shindig servers as a separate project? Or >>>> would it fit better in Rave? >>> >>> Personally I think this should be a separate project in the sense that it >>> should be able to run independently of both Wookie and Rave. Given that we >>> seem to be in agreement that Wookie should not have GUI code this means the >>> right home for the GUI would be Rave. >>> >>> However, I'd like to see the app store, with REST API, here in Wookie (as a >>> separate code base). >>> >>> If we do this then we have low level facilities here in Wookie and high >>> level GUI features in Rave. Our connector frameworks will allow other >>> platforms to build GUIs for Wookie + Wookie App Store. >>> >>> Ross >> > > -- > The Open University is incorporated by Royal Charter (RC 000391), an exempt > charity in England & Wales and a charity registered in Scotland (SC 038302).
