Greetings All,
I've updated my multi-site feature functional specification. For those
of you on the General list who aren't familiar, this is my proposal to
add explicit multi-site functionality to Bricolage. This is something I
need to do in the next few weeks, so I thought it'd be good to broaden
the feedback net on this. You'll find a copy of the spec here:
http://bricolage.cc/docs/design/MultiSite/FunctionalSpec.html
For those who are interested, you can follow the discussion so far on
the -Devel list here:
http://sourceforge.net/mailarchive/message.php?msg_id=3835591
Changes since the first version:
* I added mention of PIRT's mod_rewrite solution for stripping out the
site-specific part of URLs in request to stories published from a
current Bricolage installation managing multiple sites.
* Firmed up some of the language regarding when objects are associated
with a single site vs. when they can be associated with multiple sites.
* Based on some thinking triggered by Sam's feedback, I've decided that
elements must be uniquely named system-wide. This will keep template
development fairly straight-forward. If I'm feeling ambitious, I'll add
a new "key_name" attribute to Elements when I implement this beast, so
that even if they have globally-unique named identifiers, they can have
non-unique labels. Probably wouldn't be too hard to do, actually.
* Decided to keep output channels associated with top-level elements,
at least for now. Thanks for the feedback on that question. This means
that the selection of the default profile is no longer relevant in the
Site profile.
* Added a new option for the "Site Context" select list to allow no
context. This is so that users who want to see *all* of the workflows
they have access to in *all* of the sites they have access to will see
them. I'll probably actually set this up with a configuration directive
so it can be turned on and off.
* Expanded the description of the issues involved in allowing users
with READ-only access to stories to edit the site associations.
I consider the issue of allowing users with READ-only access to stories
to edit the site associations to be the last major hurdle to overcome
before finalizing this proposal. I cover it in the "QUESTIONS" section,
and would appreciate hearing others' views.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general
I've updated my multi-site feature functional specification. For those
of you on the General list who aren't familiar, this is my proposal to
add explicit multi-site functionality to Bricolage. This is something I
need to do in the next few weeks, so I thought it'd be good to broaden
the feedback net on this. You'll find a copy of the spec here:
http://bricolage.cc/docs/design/MultiSite/FunctionalSpec.html
For those who are interested, you can follow the discussion so far on
the -Devel list here:
http://sourceforge.net/mailarchive/message.php?msg_id=3835591
Changes since the first version:
* I added mention of PIRT's mod_rewrite solution for stripping out the
site-specific part of URLs in request to stories published from a
current Bricolage installation managing multiple sites.
* Firmed up some of the language regarding when objects are associated
with a single site vs. when they can be associated with multiple sites.
* Based on some thinking triggered by Sam's feedback, I've decided that
elements must be uniquely named system-wide. This will keep template
development fairly straight-forward. If I'm feeling ambitious, I'll add
a new "key_name" attribute to Elements when I implement this beast, so
that even if they have globally-unique named identifiers, they can have
non-unique labels. Probably wouldn't be too hard to do, actually.
* Decided to keep output channels associated with top-level elements,
at least for now. Thanks for the feedback on that question. This means
that the selection of the default profile is no longer relevant in the
Site profile.
* Added a new option for the "Site Context" select list to allow no
context. This is so that users who want to see *all* of the workflows
they have access to in *all* of the sites they have access to will see
them. I'll probably actually set this up with a configuration directive
so it can be turned on and off.
* Expanded the description of the issues involved in allowing users
with READ-only access to stories to edit the site associations.
I consider the issue of allowing users with READ-only access to stories
to edit the site associations to be the last major hurdle to overcome
before finalizing this proposal. I cover it in the "QUESTIONS" section,
and would appreciate hearing others' views.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general