Workshop outline
Last modified: February 6, 2006 - 22:23
Our workshop follows directly on the related topic "Drupal Enterprise-Wide", and a number of people will participate in both. We will take advantage of this to continue discussions begun in DEW.
As we're a large session, we'll do most of our work in small groups.
- Introduction and overview (5 minutes)
- Organizing into small groups by topic (10 minutes)
Suggested topics:
- Site network discovery and registration: how do networks of sites find out about each other and connect?
- Distributed authentication: how to users gain rights on multiple sites? how can a user logging into one site share data with another site?
- Pooled data: how can content and taxonomies be shared across sites?
- Small group working sessions by topic (45 minutes)
For each group we need:
- facilitator: facilitate discussion, ensure balanced participation
- summarizer: summarize relevant discussions from Drupal Enterprise-Wide
- recorder: take notes, ideally on laptop
- ensure you have everyone's contact information
- pay particular attention to who is taking on what piece
Small group discussion suggested format:
- quick introductions: name, hometown, groups/companies/projects worked for, and 1 sentence on a question or interest you bring to the discussion. Example: "I'm Nedjo Rogers, I'm from Victoria, Canada, I work with CivicSpace, and I'm interested in how we can extend the Drupal module to be used for connecting up different sites."
- Problem definition: agree on a basic description of the entended outcome of the solution component.
- Status overview: discuss existing options or new initiatives, with an emphasis on what they do but what else would be needed.
- Next steps: From the list of existing options or new initiatives identified, choose one or two for further development.
- Report back (15 minutes)
- Wrapup (5 min)
Report back from each small group, focusing on action items
Whole group discussion of conclusions and next directions
Relationships between sites and a network of servers
It is important to be able to fine-tune relationships. Say you have three sites: A, B & C. B might want to share members with both A & C, but A may only want to share with B (but not C), and C only with B (but not A). Also, reciprocal relationships should not be assumed. It should be possible to share only one way. For example A might want to share its members with B, while B doesn’t want to share its members with A. Of course A has to consent to sharing its resources to B. If you can’t specify whom you’re sharing your resources with, and which resources, this won’t be successful. This, of course, is the problem with the current Drupal sharing scheme.
Please see this page for more comments on how this feature might be applied in real situations.
As for how sites discover each other, i suppose having the ability to advertise your site on a central server might be one way, and even desirable for some applications, but we should not assume that all sites interested in sharing resources want to publicly advertise the fact. In other words, some sites may prefer to do it by a private invitation-only arrangement.
I could envision a field in a Sharing administration module whereby you enter a site URI and hit a “send invitation” button. Some kind of public-key signed message is sent to the targeted site which looks at the message, verifies the key with your site, and then mails the invitation to the site’s administrator. That administrator then goes to his/her Sharing administration module, sees an invitation from the originating site, and either grants or rejects selected access.
The Sharing administration module could be a place where you view all the sites you have granted access (and where you can change or revoke their access), all the sites to which you are subscribed, and where you can control which resources you wish to share and how. You may, for example, wish to share your taxonomies publicly (i.e. grant read-only access to anyone wishing to subscribe, and not requiring an invitation), share your nodes only to members of a certain group, and share your membership only upon invitation. You may want to advertise certain resources publicly, but not others. Some resources you may wish to cloak from the outside (i.e. stealth mode).
For those wishing to advertise their sites/resources, a centralized resource server could make that information available. If the Sharing admin module had a checkbox to establish such a server, it would allow for servers specific to a certain theme to be created. Drupal.org could maintain a de-facto master server of servers. So, for example, you might go out to Drupal.org’s master server and find a server which indexes sites interested in various topics like neighborhood activism, political campaigns, backpacking, environmental protection, MacOS X, or whatever. Of course a “site” could be either an actual site, or a server of sites (thus servers can cascade down to whatever degree of granularity is required). You would have have an area in the Sharing admin module where you can specify the servers with which you would like to register. This would allow for the creation of a closed network of servers, or to open it up to the public in a web of connected servers (with Drupal.org acting as a hub). It is important that the URI to the server is not fixed for any given Drupal site (i.e. you should be able to set your own URI) otherwise bots would be able to discover the existence of your server. You should be able to hide your server from the outside world, if that is what you want.