Core vs Non-Core

[Scott Wilson <sc...@gmail.com>]

Just kicking off a new thread here, as its something we need to think about for future direction.

The core purpose of Wookie is to be a W3C Widget server, however it also does some "other stuff". At the moment, we build the whole project in one go. However, it may be useful to have non-core modules as optional builds rather than core functionality.

Steve mentions Wave as one example. The Wave feature is a very nice one, but isn't a core W3C Widget feature. So this might be factored out into an optional module (you could use either the Java/DWR or NodeJS implementations)

Another one is JCR support. Currently Wookie is built with both JPA and JCR persistence - should JCR be an optional, pluggable module rather than built-in? 

Here's my strawman:

Core
====
Parser
Widget API
Widget Instances API
Properties API
WhiteList API
Participants API
Flatpack API
API Key API (todo)
W3C Widget API (metadata, preferences)
W3C Widget Updates
W3C WARP
JPA Persistence
Proxy
JQuery Mobile feature
Basic example widgets

Optional
=======
Wave Feature
oAuth Feature  (todo)
JCR Persistence
OpenSocial integration
Scratchpad widgets

(NB this is just the server, not the connectors sub-project)

I'm not sure about "services" (effectively, tags) as to whether this really is Wookie core functionality or something a "widget store" like Rave's would add on top, e.g. user-generated tagging.

S

On 11 May 2011, at 09:25, Steve Lee wrote:

> 
>> Wookie is focussed on providing a server based environment for the hosting
>> of Widgets and Gadgets. It provides the necessary infrastructure for clients
>> to request a widget/gadget instance (or a wgt package if appropriate). It
>> also provides a persistence layer so that widgets/gadgets can store
>> preference values. Wookie does not concern itself with the rendering of
>> those widgets/gadgets.
> 
> I may be getting confused but doesn't Wookie also implement Wave APIs
> - do these really belong there as well? But that's another
> discussion....

Re: Core vs Non-Core

[Ross Gardler <rg...@apache.org>]

+1 for commit - please ensure your docs below also go into the CMS

Sent from my mobile device (so please excuse typos)

On 11 May 2011, at 15:37, Scott Wilson <sc...@gmail.com> wrote:

> 
> On 11 May 2011, at 12:29, Scott Wilson wrote:
>> On 11 May 2011, at 12:08, Ross Gardler wrote:
>> 
>>> On 11/05/2011 10:21, Scott Wilson wrote:
>>>> Just kicking off a new thread here, as its something we need to think
>>>> about for future direction.
>>>> 
>>>> The core purpose of Wookie is to be a W3C Widget server, however it
>>>> also does some "other stuff". At the moment, we build the whole
>>>> project in one go. However, it may be useful to have non-core modules
>>>> as optional builds rather than core functionality.
>>>> 
>>>> Steve mentions Wave as one example. The Wave feature is a very nice
>>>> one, but isn't a core W3C Widget feature. So this might be factored
>>>> out into an optional module (you could use either the Java/DWR or
>>>> NodeJS implementations)
>>>> 
>>>> Another one is JCR support. Currently Wookie is built with both JPA
>>>> and JCR persistence - should JCR be an optional, pluggable module
>>>> rather than built-in?
>>> 
>>> How do you imagine these optional components being managed? At build time? At runtime?
>>> 
>>> The holy grail would be auto-configuration at runtime. That is, if a widget indicates it requires a non-core feature Wookie tries to find an implementation, downloads it and installs it (obviously with tight admin controls).
>>> 
>>> Currently we require features to be added at compile time. This is not very satisfactory. Whilst considering what is/is not core we perhaps ought to think about an extension mechanism too. I'm not suggesting holding up progress on this proposal until we have an extension mechanism ready. Buildtime configuration is fine as a starting point, but having a vision of where we think we are going would be a good idea.
>> 
>> Yes, for feature installs I'd really like to do something better than what we have now. There really is no reason these have to be Java classes, they could just as easily be XML config files loaded at runtime; they were patterned after the Wave feature extension which had a lot more server-side custom code, but that may be better treated as the exception rather than the template.
>> 
>> So a future model could be feature packages with:
>> 
>> /myfeature
>>    feature.xml
>>    (various js and css files)
>> 
>> ... where "feature.xml" is something like:
>> 
>> <feature>
>>  <name>http://jquerymobile.com</name>
>>  <script src="jquery-1.5.min.js"/>
>>  <script src="jquery.mobile-1.0a4-patched.min.js"/>
>>  <stylesheet src="jquery.mobile-1.0a4.min.css"/>
>> </feature>
>> 
>> (which is quite similar to how Shindig manages features)
> 
> 
> As this is something I've been meaning to do for ages, I added a ticket for it and went ahead and implemented this. Its quite a bit of refactoring (mostly deletions) but it doesn't look like it breaks any tests.
> 
> The new approach loads Features on start by inspecting the /features folder of the local installation and then creating Feature objects for each valid feature.xml file. It holds these in a static List rather than saving them in the database (its only ever going to be a few small objects and doesn't need any query support).  
> 
> This could be extended relatively easily to include a folder watcher to dynamically install features (similar to widgets) or to dynamically discover and install features if they're needed for a widget (the UC Ross mentioned above) as Feature no longer require any compilation steps.
> 
> I'm ready to commit this - I just wanted to give everyone a chance to comment/object before I went ahead.
> 
> 
>> 
>>> 
>>>> Here's my strawman:
>>> 
>>> JQuery Mobile is one of many possible frameworks so I'd make this non-core.
>>> 
>>> As a general guide I would say anything added as a <feature...> in config.xml should be non-core.
>>> 
>>> I'd also make the widget examples non-core as they will clutter up a live install. It's easy enough to add something to the CLI along the lines of:
>>> 
>>> wookie installPack widgetSamples
>>> 
>>> This would get a list of widgets in the "widgetSamples" pack and deploy them to a running instance.
>>> 
>>> I have an idea for how this "pack" thing could work. It's just a convenience for managing groups of widgets from the command line. If we manage to get runtime deployment of features then these packs could include appropriate features. I'll implement this in the CLI if we head in this direction.
>>> 
>>>> (NB this is just the server, not the connectors sub-project)
>>> 
>>> +1 I don't think any of the connectors should be part of core. They are for deployment on other platforms.
>>> 
>>>> I'm not sure about "services" (effectively, tags) as to whether this
>>>> really is Wookie core functionality or something a "widget store"
>>>> like Rave's would add on top, e.g. user-generated tagging.
>>> 
>>> I have no idea what they are for, so I guess they are not core for me ;-)
>>> 
>>> Ross
>> 
> 

Re: Core vs Non-Core

[Paul Sharples <p....@bolton.ac.uk>]

On 11/05/2011 16:02, Scott Wilson wrote:
> On 11 May 2011, at 15:37, Scott Wilson wrote:
>
>> On 11 May 2011, at 12:29, Scott Wilson wrote:
>>> On 11 May 2011, at 12:08, Ross Gardler wrote:
>>>
>>>> On 11/05/2011 10:21, Scott Wilson wrote:
>>>>> Just kicking off a new thread here, as its something we need to think
>>>>> about for future direction.
>>>>>
>>>>> The core purpose of Wookie is to be a W3C Widget server, however it
>>>>> also does some "other stuff". At the moment, we build the whole
>>>>> project in one go. However, it may be useful to have non-core modules
>>>>> as optional builds rather than core functionality.
>>>>>
>>>>> Steve mentions Wave as one example. The Wave feature is a very nice
>>>>> one, but isn't a core W3C Widget feature. So this might be factored
>>>>> out into an optional module (you could use either the Java/DWR or
>>>>> NodeJS implementations)
>>>>>
>>>>> Another one is JCR support. Currently Wookie is built with both JPA
>>>>> and JCR persistence - should JCR be an optional, pluggable module
>>>>> rather than built-in?
>>>> How do you imagine these optional components being managed? At build time? At runtime?
>>>>
>>>> The holy grail would be auto-configuration at runtime. That is, if a widget indicates it requires a non-core feature Wookie tries to find an implementation, downloads it and installs it (obviously with tight admin controls).
>>>>
>>>> Currently we require features to be added at compile time. This is not very satisfactory. Whilst considering what is/is not core we perhaps ought to think about an extension mechanism too. I'm not suggesting holding up progress on this proposal until we have an extension mechanism ready. Buildtime configuration is fine as a starting point, but having a vision of where we think we are going would be a good idea.
>>> Yes, for feature installs I'd really like to do something better than what we have now. There really is no reason these have to be Java classes, they could just as easily be XML config files loaded at runtime; they were patterned after the Wave feature extension which had a lot more server-side custom code, but that may be better treated as the exception rather than the template.
>>>
>>> So a future model could be feature packages with:
>>>
>>> /myfeature
>>>      feature.xml
>>>      (various js and css files)
>>>
>>> ... where "feature.xml" is something like:
>>>
>>> <feature>
>>>    <name>http://jquerymobile.com</name>
>>>    <script src="jquery-1.5.min.js"/>
>>>    <script src="jquery.mobile-1.0a4-patched.min.js"/>
>>>    <stylesheet src="jquery.mobile-1.0a4.min.css"/>
>>> </feature>
>>>
>>> (which is quite similar to how Shindig manages features)
>
> As this is something I've been meaning to do for ages, I added a ticket for it and went ahead and implemented this. Its quite a bit of refactoring (mostly deletions) but it doesn't look like it breaks any tests.
>
> The new approach loads Features on start by inspecting the /features folder of the local installation and then creating Feature objects for each valid feature.xml file. It holds these in a static List rather than saving them in the database (its only ever going to be a few small objects and doesn't need any query support).
>
> This could be extended relatively easily to include a folder watcher to dynamically install features (similar to widgets) or to dynamically discover and install features if they're needed for a widget (the UC Ross mentioned above) as Feature no longer require any compilation steps.
>
> I'm ready to commit this - I just wanted to give everyone a chance to comment/object before I went ahead.

+ 1

Paul
>
>>>>> Here's my strawman:
>>>> JQuery Mobile is one of many possible frameworks so I'd make this non-core.
>>>>
>>>> As a general guide I would say anything added as a<feature...>  in config.xml should be non-core.
>>>>
>>>> I'd also make the widget examples non-core as they will clutter up a live install. It's easy enough to add something to the CLI along the lines of:
>>>>
>>>> wookie installPack widgetSamples
>>>>
>>>> This would get a list of widgets in the "widgetSamples" pack and deploy them to a running instance.
>>>>
>>>> I have an idea for how this "pack" thing could work. It's just a convenience for managing groups of widgets from the command line. If we manage to get runtime deployment of features then these packs could include appropriate features. I'll implement this in the CLI if we head in this direction.
> +1 sounds good, I like the idea of "packs".
>
>>>>> (NB this is just the server, not the connectors sub-project)
>>>> +1 I don't think any of the connectors should be part of core. They are for deployment on other platforms.
>>>>
>>>>> I'm not sure about "services" (effectively, tags) as to whether this
>>>>> really is Wookie core functionality or something a "widget store"
>>>>> like Rave's would add on top, e.g. user-generated tagging.
>>>> I have no idea what they are for, so I guess they are not core for me ;-)
>>>>
>>>> Ross
>

Re: Core vs Non-Core

[Scott Wilson <sc...@gmail.com>]

On 11 May 2011, at 15:37, Scott Wilson wrote:

> 
> On 11 May 2011, at 12:29, Scott Wilson wrote:
>> On 11 May 2011, at 12:08, Ross Gardler wrote:
>> 
>>> On 11/05/2011 10:21, Scott Wilson wrote:
>>>> Just kicking off a new thread here, as its something we need to think
>>>> about for future direction.
>>>> 
>>>> The core purpose of Wookie is to be a W3C Widget server, however it
>>>> also does some "other stuff". At the moment, we build the whole
>>>> project in one go. However, it may be useful to have non-core modules
>>>> as optional builds rather than core functionality.
>>>> 
>>>> Steve mentions Wave as one example. The Wave feature is a very nice
>>>> one, but isn't a core W3C Widget feature. So this might be factored
>>>> out into an optional module (you could use either the Java/DWR or
>>>> NodeJS implementations)
>>>> 
>>>> Another one is JCR support. Currently Wookie is built with both JPA
>>>> and JCR persistence - should JCR be an optional, pluggable module
>>>> rather than built-in?
>>> 
>>> How do you imagine these optional components being managed? At build time? At runtime?
>>> 
>>> The holy grail would be auto-configuration at runtime. That is, if a widget indicates it requires a non-core feature Wookie tries to find an implementation, downloads it and installs it (obviously with tight admin controls).
>>> 
>>> Currently we require features to be added at compile time. This is not very satisfactory. Whilst considering what is/is not core we perhaps ought to think about an extension mechanism too. I'm not suggesting holding up progress on this proposal until we have an extension mechanism ready. Buildtime configuration is fine as a starting point, but having a vision of where we think we are going would be a good idea.
>> 
>> Yes, for feature installs I'd really like to do something better than what we have now. There really is no reason these have to be Java classes, they could just as easily be XML config files loaded at runtime; they were patterned after the Wave feature extension which had a lot more server-side custom code, but that may be better treated as the exception rather than the template.
>> 
>> So a future model could be feature packages with:
>> 
>> /myfeature
>>     feature.xml
>>     (various js and css files)
>> 
>> ... where "feature.xml" is something like:
>> 
>> <feature>
>>   <name>http://jquerymobile.com</name>
>>   <script src="jquery-1.5.min.js"/>
>>   <script src="jquery.mobile-1.0a4-patched.min.js"/>
>>   <stylesheet src="jquery.mobile-1.0a4.min.css"/>
>> </feature>
>> 
>> (which is quite similar to how Shindig manages features)


As this is something I've been meaning to do for ages, I added a ticket for it and went ahead and implemented this. Its quite a bit of refactoring (mostly deletions) but it doesn't look like it breaks any tests.

The new approach loads Features on start by inspecting the /features folder of the local installation and then creating Feature objects for each valid feature.xml file. It holds these in a static List rather than saving them in the database (its only ever going to be a few small objects and doesn't need any query support).  

This could be extended relatively easily to include a folder watcher to dynamically install features (similar to widgets) or to dynamically discover and install features if they're needed for a widget (the UC Ross mentioned above) as Feature no longer require any compilation steps.

I'm ready to commit this - I just wanted to give everyone a chance to comment/object before I went ahead.


>>>> Here's my strawman:
>>> 
>>> JQuery Mobile is one of many possible frameworks so I'd make this non-core.
>>> 
>>> As a general guide I would say anything added as a <feature...> in config.xml should be non-core.
>>> 
>>> I'd also make the widget examples non-core as they will clutter up a live install. It's easy enough to add something to the CLI along the lines of:
>>> 
>>> wookie installPack widgetSamples
>>> 
>>> This would get a list of widgets in the "widgetSamples" pack and deploy them to a running instance.
>>> 
>>> I have an idea for how this "pack" thing could work. It's just a convenience for managing groups of widgets from the command line. If we manage to get runtime deployment of features then these packs could include appropriate features. I'll implement this in the CLI if we head in this direction.

+1 sounds good, I like the idea of "packs".

>>> 
>>>> (NB this is just the server, not the connectors sub-project)
>>> 
>>> +1 I don't think any of the connectors should be part of core. They are for deployment on other platforms.
>>> 
>>>> I'm not sure about "services" (effectively, tags) as to whether this
>>>> really is Wookie core functionality or something a "widget store"
>>>> like Rave's would add on top, e.g. user-generated tagging.
>>> 
>>> I have no idea what they are for, so I guess they are not core for me ;-)
>>> 
>>> Ross
>> 
> 

Re: Core vs Non-Core

[Scott Wilson <sc...@gmail.com>]

On 11 May 2011, at 12:29, Scott Wilson wrote:
> On 11 May 2011, at 12:08, Ross Gardler wrote:
> 
>> On 11/05/2011 10:21, Scott Wilson wrote:
>>> Just kicking off a new thread here, as its something we need to think
>>> about for future direction.
>>> 
>>> The core purpose of Wookie is to be a W3C Widget server, however it
>>> also does some "other stuff". At the moment, we build the whole
>>> project in one go. However, it may be useful to have non-core modules
>>> as optional builds rather than core functionality.
>>> 
>>> Steve mentions Wave as one example. The Wave feature is a very nice
>>> one, but isn't a core W3C Widget feature. So this might be factored
>>> out into an optional module (you could use either the Java/DWR or
>>> NodeJS implementations)
>>> 
>>> Another one is JCR support. Currently Wookie is built with both JPA
>>> and JCR persistence - should JCR be an optional, pluggable module
>>> rather than built-in?
>> 
>> How do you imagine these optional components being managed? At build time? At runtime?
>> 
>> The holy grail would be auto-configuration at runtime. That is, if a widget indicates it requires a non-core feature Wookie tries to find an implementation, downloads it and installs it (obviously with tight admin controls).
>> 
>> Currently we require features to be added at compile time. This is not very satisfactory. Whilst considering what is/is not core we perhaps ought to think about an extension mechanism too. I'm not suggesting holding up progress on this proposal until we have an extension mechanism ready. Buildtime configuration is fine as a starting point, but having a vision of where we think we are going would be a good idea.
> 
> Yes, for feature installs I'd really like to do something better than what we have now. There really is no reason these have to be Java classes, they could just as easily be XML config files loaded at runtime; they were patterned after the Wave feature extension which had a lot more server-side custom code, but that may be better treated as the exception rather than the template.
> 
> So a future model could be feature packages with:
> 
> /myfeature
>     feature.xml
>     (various js and css files)
> 
> ... where "feature.xml" is something like:
> 
> <feature>
>   <name>http://jquerymobile.com</name>
>   <script src="jquery-1.5.min.js"/>
>   <script src="jquery.mobile-1.0a4-patched.min.js"/>
>   <stylesheet src="jquery.mobile-1.0a4.min.css"/>
> </feature>
> 
> (which is quite similar to how Shindig manages features)


As this is something I've been meaning to do for ages, I added a ticket for it and went ahead and implemented this. Its quite a bit of refactoring (mostly deletions) but it doesn't look like it breaks any tests.

The new approach loads Features on start by inspecting the /features folder of the local installation and then creating Feature objects for each valid feature.xml file. It holds these in a static List rather than saving them in the database (its only ever going to be a few small objects and doesn't need any query support).  

This could be extended relatively easily to include a folder watcher to dynamically install features (similar to widgets) or to dynamically discover and install features if they're needed for a widget (the UC Ross mentioned above) as Feature no longer require any compilation steps.

I'm ready to commit this - I just wanted to give everyone a chance to comment/object before I went ahead.


> 
>> 
>>> Here's my strawman:
>> 
>> JQuery Mobile is one of many possible frameworks so I'd make this non-core.
>> 
>> As a general guide I would say anything added as a <feature...> in config.xml should be non-core.
>> 
>> I'd also make the widget examples non-core as they will clutter up a live install. It's easy enough to add something to the CLI along the lines of:
>> 
>> wookie installPack widgetSamples
>> 
>> This would get a list of widgets in the "widgetSamples" pack and deploy them to a running instance.
>> 
>> I have an idea for how this "pack" thing could work. It's just a convenience for managing groups of widgets from the command line. If we manage to get runtime deployment of features then these packs could include appropriate features. I'll implement this in the CLI if we head in this direction.
>> 
>>> (NB this is just the server, not the connectors sub-project)
>> 
>> +1 I don't think any of the connectors should be part of core. They are for deployment on other platforms.
>> 
>>> I'm not sure about "services" (effectively, tags) as to whether this
>>> really is Wookie core functionality or something a "widget store"
>>> like Rave's would add on top, e.g. user-generated tagging.
>> 
>> I have no idea what they are for, so I guess they are not core for me ;-)
>> 
>> Ross
> 

Re: Core vs Non-Core

[Scott Wilson <sc...@gmail.com>]

On 11 May 2011, at 12:08, Ross Gardler wrote:

> On 11/05/2011 10:21, Scott Wilson wrote:
>> Just kicking off a new thread here, as its something we need to think
>> about for future direction.
>> 
>> The core purpose of Wookie is to be a W3C Widget server, however it
>> also does some "other stuff". At the moment, we build the whole
>> project in one go. However, it may be useful to have non-core modules
>> as optional builds rather than core functionality.
>> 
>> Steve mentions Wave as one example. The Wave feature is a very nice
>> one, but isn't a core W3C Widget feature. So this might be factored
>> out into an optional module (you could use either the Java/DWR or
>> NodeJS implementations)
>> 
>> Another one is JCR support. Currently Wookie is built with both JPA
>> and JCR persistence - should JCR be an optional, pluggable module
>> rather than built-in?
> 
> How do you imagine these optional components being managed? At build time? At runtime?
> 
> The holy grail would be auto-configuration at runtime. That is, if a widget indicates it requires a non-core feature Wookie tries to find an implementation, downloads it and installs it (obviously with tight admin controls).
> 
> Currently we require features to be added at compile time. This is not very satisfactory. Whilst considering what is/is not core we perhaps ought to think about an extension mechanism too. I'm not suggesting holding up progress on this proposal until we have an extension mechanism ready. Buildtime configuration is fine as a starting point, but having a vision of where we think we are going would be a good idea.

Yes, for feature installs I'd really like to do something better than what we have now. There really is no reason these have to be Java classes, they could just as easily be XML config files loaded at runtime; they were patterned after the Wave feature extension which had a lot more server-side custom code, but that may be better treated as the exception rather than the template.

So a future model could be feature packages with:

/myfeature
    feature.xml
    (various js and css files)

... where "feature.xml" is something like:

<feature>
  <name>http://jquerymobile.com</name>
  <script src="jquery-1.5.min.js"/>
  <script src="jquery.mobile-1.0a4-patched.min.js"/>
  <stylesheet src="jquery.mobile-1.0a4.min.css"/>
</feature>

(which is quite similar to how Shindig manages features)

> 
>> Here's my strawman:
> 
> JQuery Mobile is one of many possible frameworks so I'd make this non-core.
> 
> As a general guide I would say anything added as a <feature...> in config.xml should be non-core.
> 
> I'd also make the widget examples non-core as they will clutter up a live install. It's easy enough to add something to the CLI along the lines of:
> 
> wookie installPack widgetSamples
> 
> This would get a list of widgets in the "widgetSamples" pack and deploy them to a running instance.
> 
> I have an idea for how this "pack" thing could work. It's just a convenience for managing groups of widgets from the command line. If we manage to get runtime deployment of features then these packs could include appropriate features. I'll implement this in the CLI if we head in this direction.
> 
>> (NB this is just the server, not the connectors sub-project)
> 
> +1 I don't think any of the connectors should be part of core. They are for deployment on other platforms.
> 
>> I'm not sure about "services" (effectively, tags) as to whether this
>> really is Wookie core functionality or something a "widget store"
>> like Rave's would add on top, e.g. user-generated tagging.
> 
> I have no idea what they are for, so I guess they are not core for me ;-)
> 
> Ross

Re: Core vs Non-Core

[Ross Gardler <rg...@apache.org>]

On 11/05/2011 10:21, Scott Wilson wrote:
> Just kicking off a new thread here, as its something we need to think
> about for future direction.
>
> The core purpose of Wookie is to be a W3C Widget server, however it
> also does some "other stuff". At the moment, we build the whole
> project in one go. However, it may be useful to have non-core modules
> as optional builds rather than core functionality.
>
> Steve mentions Wave as one example. The Wave feature is a very nice
> one, but isn't a core W3C Widget feature. So this might be factored
> out into an optional module (you could use either the Java/DWR or
> NodeJS implementations)
>
> Another one is JCR support. Currently Wookie is built with both JPA
> and JCR persistence - should JCR be an optional, pluggable module
> rather than built-in?

How do you imagine these optional components being managed? At build 
time? At runtime?

The holy grail would be auto-configuration at runtime. That is, if a 
widget indicates it requires a non-core feature Wookie tries to find an 
implementation, downloads it and installs it (obviously with tight admin 
controls).

Currently we require features to be added at compile time. This is not 
very satisfactory. Whilst considering what is/is not core we perhaps 
ought to think about an extension mechanism too. I'm not suggesting 
holding up progress on this proposal until we have an extension 
mechanism ready. Buildtime configuration is fine as a starting point, 
but having a vision of where we think we are going would be a good idea.

> Here's my strawman:

JQuery Mobile is one of many possible frameworks so I'd make this non-core.

As a general guide I would say anything added as a <feature...> in 
config.xml should be non-core.

I'd also make the widget examples non-core as they will clutter up a 
live install. It's easy enough to add something to the CLI along the 
lines of:

wookie installPack widgetSamples

This would get a list of widgets in the "widgetSamples" pack and deploy 
them to a running instance.

I have an idea for how this "pack" thing could work. It's just a 
convenience for managing groups of widgets from the command line. If we 
manage to get runtime deployment of features then these packs could 
include appropriate features. I'll implement this in the CLI if we head 
in this direction.

> (NB this is just the server, not the connectors sub-project)

+1 I don't think any of the connectors should be part of core. They are 
for deployment on other platforms.

> I'm not sure about "services" (effectively, tags) as to whether this
> really is Wookie core functionality or something a "widget store"
> like Rave's would add on top, e.g. user-generated tagging.

I have no idea what they are for, so I guess they are not core for me ;-)

Ross