You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Matt Franklin (JIRA)" <ji...@apache.org> on 2011/05/04 23:23:03 UTC
[jira] [Created] (RAVE-27) Implement User Prefs
Implement User Prefs
--------------------
Key: RAVE-27
URL: https://issues.apache.org/jira/browse/RAVE-27
Project: Rave
Issue Type: Technical task
Reporter: Matt Franklin
Implement persistence of user prefs, container services and RPC callbacks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (RAVE-27) Implement User Prefs
Posted by Scott Wilson <sc...@gmail.com>.
On 6 May 2011, at 03:35, Zhenhua (Gerald) Guo wrote:
>> The other requirement I can see is to hold height and width parameters in the Widget object and push these into the view as these are obtained from the metadata in W3C widgets rather than using callbacks to set the iframe size dynamically.
>
> I am not familiar with W3C widget. In gadget, there is API to adjust
> iframe height. It can be called any time after the initialization.
> So if there is anything similar in W3C Widget, callbacks may also be
> needed to set height.
Its not part of the W3C spec, but could be added as a proprietary <feature> extension.
>
>
> Gerald
>
>>
>> S
>>
>>>
>>> -Matt
>>>
>>>>
>>>> public URL renderWidget(User user, RegionWidget regionWidget){
>>>> }
>>>>
>>>> Or is it a bit more complex than that..?
>>>>
>>>> At the site level we also need some sort of palette or menu system for
>>>> adding widgets based on what's available in available containers. The
>>>> actual metadata is mostly quite similar - titles, authors, icons etc.
>>>> Wookie exposes metadata on all available widget in its REST API. Some
>>>> user stories for how we envisage users discovering and adding
>>>> widgets/gadgets to the workspace would be useful here.
>>>>
>>>>>
>>>>> -Matt
>>>>>
>>>>> On 5/4/11 5:23 PM, "Matt Franklin (JIRA)" <ji...@apache.org> wrote:
>>>>>
>>>>>> Implement User Prefs
>>>>>> --------------------
>>>>>>
>>>>>> Key: RAVE-27
>>>>>> URL: https://issues.apache.org/jira/browse/RAVE-27
>>>>>> Project: Rave
>>>>>> Issue Type: Technical task
>>>>>> Reporter: Matt Franklin
>>>>>>
>>>>>>
>>>>>> Implement persistence of user prefs, container services and RPC
>>>>>> callbacks
>>>>>>
>>>>>> --
>>>>>> This message is automatically generated by JIRA.
>>>>>> For more information on JIRA, see:
>>>>>> http://www.atlassian.com/software/jira
>>>>>
>>>>
>>>
>>
>>
Re: [jira] [Created] (RAVE-27) Implement User Prefs
Posted by "Zhenhua (Gerald) Guo" <je...@gmail.com>.
On Thu, May 5, 2011 at 2:45 PM, Scott Wilson
<sc...@gmail.com> wrote:
>
> On 5 May 2011, at 18:00, Franklin, Matthew B. wrote:
>
>> On 5/4/11 6:25 PM, "Scott Wilson" <sc...@gmail.com> wrote:
>>
>>> On 4 May 2011, at 22:36, Franklin, Matthew B. wrote:
>>>
>>>> As we start to implement more of the OpenSocial constructs within the
>>>> container, I think it is probably appropriate to begin discussing the
>>>> impact of supporting multiple widget types on the model.
>>>>
>>>> Anyone have a strategy in mind?
>>>
>>> OpenSocial/Shindig requires a lot more plumbing than W3C Widgets/Wookie -
>>> the only hook really needed for Wookie is to get the spec for rendering a
>>> widget (title, height, width, iframe src) by calling the Wookie REST API
>>> and for telling it who's looking at it (participant id/name/icon - same
>>> as Wave). There are no data APIs or RPC hooks or anything like that
>>> needed, though we probably would want to do something to support
>>> inter-widget communication (extending Wookie to support the Shindig
>>> pubsub feature might be the easiest solution there).
>>
>> The big question in my mind right now is constructs like User Prefs. In
>> OpenSocial, UserPrefs are stored by the container via an RPC callback. I
>> know W3C widgets have preferences, but I don't know where/how you
>> envisioned them getting stored.
>
> Currently Wookie stores them itself in its own data store, so there isn't any particular need to do anything about them.
>
>>
>>>
>>> I'm assuming that the basic idea is that the Rave Widget model class is
>>> used to persist sufficient metadata about the widget (of whatever type)
>>> so that it can be rendered by the layout engine at runtime for a
>>> particular user? In which case there has to be some sort of service
>>> method (WidgetService?) that each adapter for a widget type needs to
>>> implement - did you have some ideas about what that should look like? I
>>> guess I'm imagining something along the lines of:
>>
>> I think something like this might work well for inlined widgets. In
>> OpenSocial, most widgets are not inline, and are initialized via the
>> container on the client side.
>
> Yes, I've just been exploring the code and seeing how the Shindig gadgets are being rendered. The main difference for Wookie is needing to process the Widget object with the current viewer and context before sending it to the view; e..g:
>
> public String getHome(Model model) {
> User user = userService.getAuthenticatedUser();
> List<Page> pages = pageService.getAllPages(user.getUserId());
> for (Page page: pages){
> for (Region region: page.getRegions()){
> for (RegionWidget regionWidget: region.getRegionWidgets()){
> regionWidget.setWidget(widgetService.getWidget(user, regionWidget.getId().toString(), regionWidget.getWidget()));
> }
> }
> }
>
> I've done this on my setup and it seems to work OK - I haven't committed anything as the WidgetService connects to Wookie using the Wookie Connector 0.1.0-SNAPSHOT jar which isn't in a public repository. Plus it still looks a bit hacky and clumsy :-)
>
> For rendering we can use the same approach as for OpenSocial of getting the client to render the content - I've tried it out with a script that builds an iFrame tag and appends it to the element, and that seems fine.
>
> The other requirement I can see is to hold height and width parameters in the Widget object and push these into the view as these are obtained from the metadata in W3C widgets rather than using callbacks to set the iframe size dynamically.
I am not familiar with W3C widget. In gadget, there is API to adjust
iframe height. It can be called any time after the initialization.
So if there is anything similar in W3C Widget, callbacks may also be
needed to set height.
Gerald
>
> S
>
>>
>> -Matt
>>
>>>
>>> public URL renderWidget(User user, RegionWidget regionWidget){
>>> }
>>>
>>> Or is it a bit more complex than that..?
>>>
>>> At the site level we also need some sort of palette or menu system for
>>> adding widgets based on what's available in available containers. The
>>> actual metadata is mostly quite similar - titles, authors, icons etc.
>>> Wookie exposes metadata on all available widget in its REST API. Some
>>> user stories for how we envisage users discovering and adding
>>> widgets/gadgets to the workspace would be useful here.
>>>
>>>>
>>>> -Matt
>>>>
>>>> On 5/4/11 5:23 PM, "Matt Franklin (JIRA)" <ji...@apache.org> wrote:
>>>>
>>>>> Implement User Prefs
>>>>> --------------------
>>>>>
>>>>> Key: RAVE-27
>>>>> URL: https://issues.apache.org/jira/browse/RAVE-27
>>>>> Project: Rave
>>>>> Issue Type: Technical task
>>>>> Reporter: Matt Franklin
>>>>>
>>>>>
>>>>> Implement persistence of user prefs, container services and RPC
>>>>> callbacks
>>>>>
>>>>> --
>>>>> This message is automatically generated by JIRA.
>>>>> For more information on JIRA, see:
>>>>> http://www.atlassian.com/software/jira
>>>>
>>>
>>
>
>
Re: [jira] [Created] (RAVE-27) Implement User Prefs
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 5/5/11 2:45 PM, "Scott Wilson" <sc...@gmail.com> wrote:
>
>On 5 May 2011, at 18:00, Franklin, Matthew B. wrote:
>
>> On 5/4/11 6:25 PM, "Scott Wilson" <sc...@gmail.com>
>>wrote:
>>
>>> On 4 May 2011, at 22:36, Franklin, Matthew B. wrote:
>>>
>>>> As we start to implement more of the OpenSocial constructs within the
>>>> container, I think it is probably appropriate to begin discussing the
>>>> impact of supporting multiple widget types on the model.
>>>>
>>>> Anyone have a strategy in mind?
>>>
>>> OpenSocial/Shindig requires a lot more plumbing than W3C
>>>Widgets/Wookie -
>>> the only hook really needed for Wookie is to get the spec for
>>>rendering a
>>> widget (title, height, width, iframe src) by calling the Wookie REST
>>>API
>>> and for telling it who's looking at it (participant id/name/icon - same
>>> as Wave). There are no data APIs or RPC hooks or anything like that
>>> needed, though we probably would want to do something to support
>>> inter-widget communication (extending Wookie to support the Shindig
>>> pubsub feature might be the easiest solution there).
>>
>> The big question in my mind right now is constructs like User Prefs. In
>> OpenSocial, UserPrefs are stored by the container via an RPC callback.
>>I
>> know W3C widgets have preferences, but I don't know where/how you
>> envisioned them getting stored.
>
>Currently Wookie stores them itself in its own data store, so there isn't
>any particular need to do anything about them.
Maybe there is a disconnect between W3C widget preferences and OpenSocial.
In OpenSocial, UserPrefs are modifiable by the gadget and the container
is expected to persist the preferences. They get passed to Shindig during
the rendering process as URL parameters for the iFrame. Can users update
W3c widget prefs and if so, do we want the container to persist them as it
does for OpenSocial gadgets?
>
>>
>>>
>>> I'm assuming that the basic idea is that the Rave Widget model class is
>>> used to persist sufficient metadata about the widget (of whatever type)
>>> so that it can be rendered by the layout engine at runtime for a
>>> particular user? In which case there has to be some sort of service
>>> method (WidgetService?) that each adapter for a widget type needs to
>>> implement - did you have some ideas about what that should look like? I
>>> guess I'm imagining something along the lines of:
>>
>> I think something like this might work well for inlined widgets. In
>> OpenSocial, most widgets are not inline, and are initialized via the
>> container on the client side.
>
>Yes, I've just been exploring the code and seeing how the Shindig gadgets
>are being rendered. The main difference for Wookie is needing to process
>the Widget object with the current viewer and context before sending it
>to the view; e..g:
>
> public String getHome(Model model) {
> User user = userService.getAuthenticatedUser();
> List<Page> pages = pageService.getAllPages(user.getUserId());
> for (Page page: pages){
> for (Region region: page.getRegions()){
> for (RegionWidget regionWidget:
>region.getRegionWidgets()){
> regionWidget.setWidget(widgetService.getWidget(user,
>regionWidget.getId().toString(), regionWidget.getWidget()));
> }
> }
> }
I am not sure doing this in the controller is the right place. In fact, I
am not sure where the right place to do it is at all. My preference is to
move it much closer to the rendering of the gadget, so that as you are
rendering the page you can test to see if a widget is inline and if so
call the appropriate rendering engine. IMHO, I think we should defer
inlining of widgets to 0.2 at the earliest. I think we have plenty of
work to get the page up and running with W3C and OpenSocial iFrame based
widgets.
>
>I've done this on my setup and it seems to work OK - I haven't committed
>anything as the WidgetService connects to Wookie using the Wookie
>Connector 0.1.0-SNAPSHOT jar which isn't in a public repository. Plus it
>still looks a bit hacky and clumsy :-)
>
>For rendering we can use the same approach as for OpenSocial of getting
>the client to render the content - I've tried it out with a script that
>builds an iFrame tag and appends it to the element, and that seems fine.
It would be great if the W3C widget rendering scripts mirrored the
structure of the OpenSocial stuff as much as possible. I built a
client-side mapping function that returns the widgets on a page mapped by
widget type, so you can get the W3C widgets and call
rave.w3c.initWidgets(widgets);
>
>The other requirement I can see is to hold height and width parameters in
>the Widget object and push these into the view as these are obtained from
>the metadata in W3C widgets rather than using callbacks to set the iframe
>size dynamically.
I would be +1 for adding this to the RegionWidget object and making it
available to the client runtime object.
>
>S
>
>>
>> -Matt
>>
>>>
>>> public URL renderWidget(User user, RegionWidget regionWidget){
>>> }
>>>
>>> Or is it a bit more complex than that..?
>>>
>>> At the site level we also need some sort of palette or menu system for
>>> adding widgets based on what's available in available containers. The
>>> actual metadata is mostly quite similar - titles, authors, icons etc.
>>> Wookie exposes metadata on all available widget in its REST API. Some
>>> user stories for how we envisage users discovering and adding
>>> widgets/gadgets to the workspace would be useful here.
>>>
>>>>
>>>> -Matt
>>>>
>>>> On 5/4/11 5:23 PM, "Matt Franklin (JIRA)" <ji...@apache.org> wrote:
>>>>
>>>>> Implement User Prefs
>>>>> --------------------
>>>>>
>>>>> Key: RAVE-27
>>>>> URL: https://issues.apache.org/jira/browse/RAVE-27
>>>>> Project: Rave
>>>>> Issue Type: Technical task
>>>>> Reporter: Matt Franklin
>>>>>
>>>>>
>>>>> Implement persistence of user prefs, container services and RPC
>>>>> callbacks
>>>>>
>>>>> --
>>>>> This message is automatically generated by JIRA.
>>>>> For more information on JIRA, see:
>>>>> http://www.atlassian.com/software/jira
>>>>
>>>
>>
>
Re: [jira] [Created] (RAVE-27) Implement User Prefs
Posted by Scott Wilson <sc...@gmail.com>.
On 5 May 2011, at 18:00, Franklin, Matthew B. wrote:
> On 5/4/11 6:25 PM, "Scott Wilson" <sc...@gmail.com> wrote:
>
>> On 4 May 2011, at 22:36, Franklin, Matthew B. wrote:
>>
>>> As we start to implement more of the OpenSocial constructs within the
>>> container, I think it is probably appropriate to begin discussing the
>>> impact of supporting multiple widget types on the model.
>>>
>>> Anyone have a strategy in mind?
>>
>> OpenSocial/Shindig requires a lot more plumbing than W3C Widgets/Wookie -
>> the only hook really needed for Wookie is to get the spec for rendering a
>> widget (title, height, width, iframe src) by calling the Wookie REST API
>> and for telling it who's looking at it (participant id/name/icon - same
>> as Wave). There are no data APIs or RPC hooks or anything like that
>> needed, though we probably would want to do something to support
>> inter-widget communication (extending Wookie to support the Shindig
>> pubsub feature might be the easiest solution there).
>
> The big question in my mind right now is constructs like User Prefs. In
> OpenSocial, UserPrefs are stored by the container via an RPC callback. I
> know W3C widgets have preferences, but I don't know where/how you
> envisioned them getting stored.
Currently Wookie stores them itself in its own data store, so there isn't any particular need to do anything about them.
>
>>
>> I'm assuming that the basic idea is that the Rave Widget model class is
>> used to persist sufficient metadata about the widget (of whatever type)
>> so that it can be rendered by the layout engine at runtime for a
>> particular user? In which case there has to be some sort of service
>> method (WidgetService?) that each adapter for a widget type needs to
>> implement - did you have some ideas about what that should look like? I
>> guess I'm imagining something along the lines of:
>
> I think something like this might work well for inlined widgets. In
> OpenSocial, most widgets are not inline, and are initialized via the
> container on the client side.
Yes, I've just been exploring the code and seeing how the Shindig gadgets are being rendered. The main difference for Wookie is needing to process the Widget object with the current viewer and context before sending it to the view; e..g:
public String getHome(Model model) {
User user = userService.getAuthenticatedUser();
List<Page> pages = pageService.getAllPages(user.getUserId());
for (Page page: pages){
for (Region region: page.getRegions()){
for (RegionWidget regionWidget: region.getRegionWidgets()){
regionWidget.setWidget(widgetService.getWidget(user, regionWidget.getId().toString(), regionWidget.getWidget()));
}
}
}
I've done this on my setup and it seems to work OK - I haven't committed anything as the WidgetService connects to Wookie using the Wookie Connector 0.1.0-SNAPSHOT jar which isn't in a public repository. Plus it still looks a bit hacky and clumsy :-)
For rendering we can use the same approach as for OpenSocial of getting the client to render the content - I've tried it out with a script that builds an iFrame tag and appends it to the element, and that seems fine.
The other requirement I can see is to hold height and width parameters in the Widget object and push these into the view as these are obtained from the metadata in W3C widgets rather than using callbacks to set the iframe size dynamically.
S
>
> -Matt
>
>>
>> public URL renderWidget(User user, RegionWidget regionWidget){
>> }
>>
>> Or is it a bit more complex than that..?
>>
>> At the site level we also need some sort of palette or menu system for
>> adding widgets based on what's available in available containers. The
>> actual metadata is mostly quite similar - titles, authors, icons etc.
>> Wookie exposes metadata on all available widget in its REST API. Some
>> user stories for how we envisage users discovering and adding
>> widgets/gadgets to the workspace would be useful here.
>>
>>>
>>> -Matt
>>>
>>> On 5/4/11 5:23 PM, "Matt Franklin (JIRA)" <ji...@apache.org> wrote:
>>>
>>>> Implement User Prefs
>>>> --------------------
>>>>
>>>> Key: RAVE-27
>>>> URL: https://issues.apache.org/jira/browse/RAVE-27
>>>> Project: Rave
>>>> Issue Type: Technical task
>>>> Reporter: Matt Franklin
>>>>
>>>>
>>>> Implement persistence of user prefs, container services and RPC
>>>> callbacks
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> For more information on JIRA, see:
>>>> http://www.atlassian.com/software/jira
>>>
>>
>
Re: [jira] [Created] (RAVE-27) Implement User Prefs
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 5/4/11 6:25 PM, "Scott Wilson" <sc...@gmail.com> wrote:
>On 4 May 2011, at 22:36, Franklin, Matthew B. wrote:
>
>> As we start to implement more of the OpenSocial constructs within the
>> container, I think it is probably appropriate to begin discussing the
>> impact of supporting multiple widget types on the model.
>>
>> Anyone have a strategy in mind?
>
>OpenSocial/Shindig requires a lot more plumbing than W3C Widgets/Wookie -
>the only hook really needed for Wookie is to get the spec for rendering a
>widget (title, height, width, iframe src) by calling the Wookie REST API
>and for telling it who's looking at it (participant id/name/icon - same
>as Wave). There are no data APIs or RPC hooks or anything like that
>needed, though we probably would want to do something to support
>inter-widget communication (extending Wookie to support the Shindig
>pubsub feature might be the easiest solution there).
The big question in my mind right now is constructs like User Prefs. In
OpenSocial, UserPrefs are stored by the container via an RPC callback. I
know W3C widgets have preferences, but I don't know where/how you
envisioned them getting stored.
>
>I'm assuming that the basic idea is that the Rave Widget model class is
>used to persist sufficient metadata about the widget (of whatever type)
>so that it can be rendered by the layout engine at runtime for a
>particular user? In which case there has to be some sort of service
>method (WidgetService?) that each adapter for a widget type needs to
>implement - did you have some ideas about what that should look like? I
>guess I'm imagining something along the lines of:
I think something like this might work well for inlined widgets. In
OpenSocial, most widgets are not inline, and are initialized via the
container on the client side.
-Matt
>
>public URL renderWidget(User user, RegionWidget regionWidget){
>}
>
>Or is it a bit more complex than that..?
>
>At the site level we also need some sort of palette or menu system for
>adding widgets based on what's available in available containers. The
>actual metadata is mostly quite similar - titles, authors, icons etc.
>Wookie exposes metadata on all available widget in its REST API. Some
>user stories for how we envisage users discovering and adding
>widgets/gadgets to the workspace would be useful here.
>
>>
>> -Matt
>>
>> On 5/4/11 5:23 PM, "Matt Franklin (JIRA)" <ji...@apache.org> wrote:
>>
>>> Implement User Prefs
>>> --------------------
>>>
>>> Key: RAVE-27
>>> URL: https://issues.apache.org/jira/browse/RAVE-27
>>> Project: Rave
>>> Issue Type: Technical task
>>> Reporter: Matt Franklin
>>>
>>>
>>> Implement persistence of user prefs, container services and RPC
>>>callbacks
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> For more information on JIRA, see:
>>>http://www.atlassian.com/software/jira
>>
>
Re: [jira] [Created] (RAVE-27) Implement User Prefs
Posted by Scott Wilson <sc...@gmail.com>.
On 4 May 2011, at 22:36, Franklin, Matthew B. wrote:
> As we start to implement more of the OpenSocial constructs within the
> container, I think it is probably appropriate to begin discussing the
> impact of supporting multiple widget types on the model.
>
> Anyone have a strategy in mind?
OpenSocial/Shindig requires a lot more plumbing than W3C Widgets/Wookie - the only hook really needed for Wookie is to get the spec for rendering a widget (title, height, width, iframe src) by calling the Wookie REST API and for telling it who's looking at it (participant id/name/icon - same as Wave). There are no data APIs or RPC hooks or anything like that needed, though we probably would want to do something to support inter-widget communication (extending Wookie to support the Shindig pubsub feature might be the easiest solution there).
I'm assuming that the basic idea is that the Rave Widget model class is used to persist sufficient metadata about the widget (of whatever type) so that it can be rendered by the layout engine at runtime for a particular user? In which case there has to be some sort of service method (WidgetService?) that each adapter for a widget type needs to implement - did you have some ideas about what that should look like? I guess I'm imagining something along the lines of:
public URL renderWidget(User user, RegionWidget regionWidget){
}
Or is it a bit more complex than that..?
At the site level we also need some sort of palette or menu system for adding widgets based on what's available in available containers. The actual metadata is mostly quite similar - titles, authors, icons etc. Wookie exposes metadata on all available widget in its REST API. Some user stories for how we envisage users discovering and adding widgets/gadgets to the workspace would be useful here.
>
> -Matt
>
> On 5/4/11 5:23 PM, "Matt Franklin (JIRA)" <ji...@apache.org> wrote:
>
>> Implement User Prefs
>> --------------------
>>
>> Key: RAVE-27
>> URL: https://issues.apache.org/jira/browse/RAVE-27
>> Project: Rave
>> Issue Type: Technical task
>> Reporter: Matt Franklin
>>
>>
>> Implement persistence of user prefs, container services and RPC callbacks
>>
>> --
>> This message is automatically generated by JIRA.
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
Re: [jira] [Created] (RAVE-27) Implement User Prefs
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
As we start to implement more of the OpenSocial constructs within the
container, I think it is probably appropriate to begin discussing the
impact of supporting multiple widget types on the model.
Anyone have a strategy in mind?
-Matt
On 5/4/11 5:23 PM, "Matt Franklin (JIRA)" <ji...@apache.org> wrote:
>Implement User Prefs
>--------------------
>
> Key: RAVE-27
> URL: https://issues.apache.org/jira/browse/RAVE-27
> Project: Rave
> Issue Type: Technical task
> Reporter: Matt Franklin
>
>
>Implement persistence of user prefs, container services and RPC callbacks
>
>--
>This message is automatically generated by JIRA.
>For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (RAVE-27) Implement User Prefs
Posted by "Matt Franklin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Franklin updated RAVE-27:
------------------------------
Fix Version/s: (was: 0.2-INCUBATING)
0.3-INCUBATING
> Implement User Prefs
> --------------------
>
> Key: RAVE-27
> URL: https://issues.apache.org/jira/browse/RAVE-27
> Project: Rave
> Issue Type: Story
> Reporter: Matt Franklin
> Assignee: Anthony Carlucci
> Fix For: 0.3-INCUBATING
>
>
> Implement persistence of user prefs, container services and RPC callbacks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (RAVE-27) Implement User Prefs
Posted by "Anthony Carlucci (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Anthony Carlucci reassigned RAVE-27:
------------------------------------
Assignee: Anthony Carlucci
> Implement User Prefs
> --------------------
>
> Key: RAVE-27
> URL: https://issues.apache.org/jira/browse/RAVE-27
> Project: Rave
> Issue Type: Story
> Reporter: Matt Franklin
> Assignee: Anthony Carlucci
> Fix For: 0.2-INCUBATING
>
>
> Implement persistence of user prefs, container services and RPC callbacks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (RAVE-27) Implement User Prefs
Posted by "Jesse Ciancetta (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jesse Ciancetta reassigned RAVE-27:
-----------------------------------
Assignee: Jesse Ciancetta
> Implement User Prefs
> --------------------
>
> Key: RAVE-27
> URL: https://issues.apache.org/jira/browse/RAVE-27
> Project: Rave
> Issue Type: Technical task
> Reporter: Matt Franklin
> Assignee: Jesse Ciancetta
> Fix For: 0.1-INCUBATING
>
>
> Implement persistence of user prefs, container services and RPC callbacks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (RAVE-27) Implement User Prefs
Posted by "Matt Franklin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Franklin updated RAVE-27:
------------------------------
Fix Version/s: (was: 0.1-INCUBATING)
0.2-INCUBATING
> Implement User Prefs
> --------------------
>
> Key: RAVE-27
> URL: https://issues.apache.org/jira/browse/RAVE-27
> Project: Rave
> Issue Type: New Feature
> Reporter: Matt Franklin
> Assignee: Jesse Ciancetta
> Fix For: 0.2-INCUBATING
>
>
> Implement persistence of user prefs, container services and RPC callbacks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (RAVE-27) Implement User Prefs
Posted by "Anthony Carlucci (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Anthony Carlucci resolved RAVE-27.
----------------------------------
Resolution: Fixed
All sub tasks for RAVE-27 have been resolved
> Implement User Prefs
> --------------------
>
> Key: RAVE-27
> URL: https://issues.apache.org/jira/browse/RAVE-27
> Project: Rave
> Issue Type: Story
> Reporter: Matt Franklin
> Assignee: Anthony Carlucci
> Fix For: 0.2-INCUBATING
>
>
> Implement persistence of user prefs, container services and RPC callbacks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (RAVE-27) Implement User Prefs
Posted by "Matt Franklin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Franklin updated RAVE-27:
------------------------------
Issue Type: New Feature (was: Technical task)
Parent: (was: RAVE-12)
> Implement User Prefs
> --------------------
>
> Key: RAVE-27
> URL: https://issues.apache.org/jira/browse/RAVE-27
> Project: Rave
> Issue Type: New Feature
> Reporter: Matt Franklin
> Assignee: Jesse Ciancetta
> Fix For: 0.2-INCUBATING
>
>
> Implement persistence of user prefs, container services and RPC callbacks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (RAVE-27) Implement User Prefs
Posted by "Matt Franklin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Franklin updated RAVE-27:
------------------------------
Issue Type: Story (was: New Feature)
> Implement User Prefs
> --------------------
>
> Key: RAVE-27
> URL: https://issues.apache.org/jira/browse/RAVE-27
> Project: Rave
> Issue Type: Story
> Reporter: Matt Franklin
> Assignee: Jesse Ciancetta
> Fix For: 0.2-INCUBATING
>
>
> Implement persistence of user prefs, container services and RPC callbacks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (RAVE-27) Implement User Prefs
Posted by "Matt Franklin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Franklin updated RAVE-27:
------------------------------
Fix Version/s: 0.1-INCUBATING
> Implement User Prefs
> --------------------
>
> Key: RAVE-27
> URL: https://issues.apache.org/jira/browse/RAVE-27
> Project: Rave
> Issue Type: Technical task
> Reporter: Matt Franklin
> Fix For: 0.1-INCUBATING
>
>
> Implement persistence of user prefs, container services and RPC callbacks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (RAVE-27) Implement User Prefs
Posted by "Jesse Ciancetta (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jesse Ciancetta reassigned RAVE-27:
-----------------------------------
Assignee: (was: Jesse Ciancetta)
> Implement User Prefs
> --------------------
>
> Key: RAVE-27
> URL: https://issues.apache.org/jira/browse/RAVE-27
> Project: Rave
> Issue Type: Story
> Reporter: Matt Franklin
> Fix For: 0.2-INCUBATING
>
>
> Implement persistence of user prefs, container services and RPC callbacks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira