On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
[
https://issues.apache.org/jira/browse/RAVE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231993#comment-13231993
]
Scott Wilson commented on RAVE-103:
-----------------------------------
I think there are two models we can look at:
1. Page Sharing
In this model, a user creates a new page, and from the tab context menu selects "Share this
page...". A dialog opens, and the user can add people (e.g. using a search/filter view), or
select an existing group (e.g. friends, family, co-workers...). The user chooses OK, and each user
is notified when they log into Rave of the invitation to add the shared Page. The user who created
the Page is the Owner; each user they share with is by default a Viewer (read-only). However, it
should be possible for the Owner to grant other users a "Can Edit" role allowing them to
add, remove and move widgets.
2. Workspace Sharing
In this model, there is a higher-level entity comprising a collection of
multiple pages managed by a group. New shared pages can be added as sub-pages
of the top-level workspace. I'm a bit less clear on the workflow for this one,
whether its the same as (1) but with sub-pages, or something conceptually quite
different
IMO we should (eventually) strive to merge both these models into one logical
model from Rave perspective.
For one, we already have a 'shared' page right now: the profile page. With sub
pages...
IMO the current separate/special handling of the profile page should technically
or model wise not be special at all. What difference is there between sharing
'a' page to the public with sharing 'the' profile page(s) to the public?
To me this seems like just a matter of security configuration, with the profile
page 'just' representing a common default 'share'.
Interestingly, the current profile page also now has 'sub' pages, which in a
minimalistic sense maybe could be regarded as a shared 'workspace' already (with
a single owner).
I'm interested in how adding a shared page to the users view of pages will work
out.
Right now we do not have yet a navigational representation of pages.
Will sharing the canonical 'Main' page with john.doe result in two 'Main' pages
to be shown? As the name of a page (currently) is only stored in the page
itself, to prevent 'namespace' clashes, you either need to:
- 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
/person/canonical/pages/Main), or
- allow the viewer to *locally* rename that page (ugh: Main1, Main2, Main3), or
- introduce a mounting or shortcut like feature where the viewer can structure
its own 'site' and 'inject' shared pages at any desired location, or
- ...?
Note: in the above options I'm not referring to page IDs anymore. While each
page can/should still be addressable by ID (too), if you're going to share pages
you'll need *also* a logical naming representation to be able for the viewer to
navigate its own 'site' or even more so a public/anonymous view of 'the' site.
Meaning: we'll need to come up with a navigational structure for pages which can
be rendered through menu's, site maps, etc. These IMO should be accessible and
represented as REST resources like the web itself. Thus hierarchically structured.
Once we get there, I think the workspace vs page discussion becomes easier and
more 'structured'. A workspace then can simply represent a parent (or root) page
resource with optional children which happens to be shared, somehow.
Important this IMO is a discussion on ownership of a shared page or workspace,
something which was also discussed, but IMO not concluded, recently on the
OpenSocial 3.0 kickoff concerning the Spaces proposal.
I think each page/space/workspace or whatever (Rave) 'social' web resource
should have a canonical owner. Meaning only one. And if you want to 'share'
ownership, then a separate and standalone entity like Group should be used.
Because that will then allow providing both a canonical location (url).
Consider for instance searching (public web or from within the portal) and
finding an entry matching a page or workspace: what or who's canonical url
should be linked to if you would have multiple owners?
There are many different ways to represent a site structure and also many
different ways to logically blend or merge/share/overlay logical structures on
top of it, but I think it would be useful to start with something which as a
minimum provides a canonical representation of the Rave site, and leverage that
as a start for sharing purposes, without any need to 'OK' a shared page before
it becomes 'visible'.
So for example canonical could have the following 'pages':
/portal/app/my/profile
/portal/app/my/profile/about
/portal/app/my/profile/activities
/portal/app/my/pages/main
/portal/app/my/pages/social
and have its /profile, /profile/about and /pages/social pages shared with
john.doe.
Then, john.doe might be able to see (and have menu/links) to:
/portal/app/my/profile
/portal/app/my/profile/about
/portal/app/my/profile/activities
/portal/app/my/pages/main
/portal/app/my/pages/social
/portal/app/person/canonical/profile
/portal/app/person/canonical/profile/about
/portal/app/person/canonical/pages/social
Of course the above url structure is just an example.
As soon as I have a bit more time I can try to better explain it, but hopefully
it makes sense somewhat.
Ate
====
Paul and I are really interested in seeing if we can develop something along
the lines of model (1) in a sprint next week as it would be a good fit for a
project we're working on. This wouldn't include the OpenSocial Spaces
extension (I'm sure someone else could implement it later) but would include
the basic functionality of sharing pages, selecting users, and extending the
relevant PermissionEvaluator classes for non-Owner roles.
Support shared spaces
---------------------
Key: RAVE-103
URL: https://issues.apache.org/jira/browse/RAVE-103
Project: Rave
Issue Type: Epic
Reporter: Matt Franklin
Support shared, or common, spaces with group managed pages, widgets, and
security
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
