On 16/05/2011 22:28, Scott Wilson wrote:
On 16 May 2011, at 16:46, Lucas Anastasiou wrote:
...
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.?
+1 for including this in Wookie itself. Although bear in mind that we
are currently discussing a separation of GUI from Wookie. This means
that we would need to implement this (and any other new features) in the
API.
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.
This would be a quick and easy way to implement this, it would amount to
a couple of config lines in log4j.properties and a logging line in the
widget instantiation code. If there are a very large number of
concurrent users this might need to be reconsidered.
3. Inter-widget communication dependency modelling:
...
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.
+1, even if there are licence issues please let us see the code. I need
inter-widget communications and might be able to find the time to work
around any issues.
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.
+1, lets work together on this in a sub-project aligned with the main
Wookie development.
By the sounds of it the approach you have taken to date is likely to
lead you down a long dark ally where you will find it difficult to stay
updated with the work we do here. If you continue to give us visibility
into your work we can seek to align changes in Wookie to your needs. We
get the benefit of your code, you get a lower maintenance cost.
Ross
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).
