> In TiddlyDocs, for example, each "room" is a group of people who can
> share documents together. If you're only in room A, you have no
> visibility on content in room B. Some of the early design is described
> at http://softwareas.com/tiddlydocs-user-authentication-generic-design-and-custom-features,
> but maybe Simon or Ben can provide an update on that.
How is this different from two bags with two different policies? Is "room" a label for describing a way of managing bags, or is it an entity that is reified in the system in some way?
Again, I see this as making a statement about a thing called rooms, for which there has been no statement of requirements and by using it the full flexibility of RBPR is being limited.
Every time a new bag or recipe is created, it's policy can be set to whatever the system designer wants it to be.
The policy can be changed any time the system designer wants it to be.
The policy can be dynamically altered in place, temporarily, per request, based on environmental conditions.
Every time a new user is created, they can be given whatever roles are required as defined by the system designer.
These roles can be change any time the system designer wants.
Every time a user is instantiated, per request, their roles can be dynamically set or altered, per request, based on environmental conditions.
Recipes and bags are designed to be cheap to create, cheap to use, and cheap to destroy. It's okay for a system to have loads and loads of them. Similarly it is okay for a system to have loads and loads of roles. A thing lacking in the TiddlyWeb-sphere are the tools to easily manage and inspect these loads and loads of stuff, so I think people are tending towards systems which use as few RBPR as they can get away with. I think this is the wrong approach.
Implicit in that is a separation between the creation of a contained "space" and the actions done to let people in. In 2 or 3 above the "let people in" is done by modifying the people, not by modifying the space. The space has already been defined.
http://softwareas.com/multi-user-tiddlywiki
I've switched off comments on that post to encourage them to go here instead.
> I wrote about the multi-user concept at a high-level on my blog, and
> I'd encourage any interested parties to have a read as there are
> floating bears and a thousand flowers involved:
>
> http://softwareas.com/multi-user-tiddlywiki
Coolest thing about your vision - I thought - was the idea of a
standardised piece of software that you could install on your
enterprisey server and get a TiddlyWeb MU going whereby ANY app you
wanted to create was creatable. In doing this, you make a simple path
for people to get started with TiddlyWeb, even if it means they end up
downloading and installing more than they need. For people with an
advanced understanding, they can use one of the paths we're talking
about in the "packaging" discussions.
I liked the story too.
J.
Thanks for the feedback Jon. I should make it clear that the general
concept is not just my vision, but something we've bandied about in
Osmosoft and also an idea you've contributed to yourself :)
Also, although I've focused on the enterprise concept, it could easily
work as a public internet service too. Perhaps with some tweaks, like
different subdomains per rooms for security (and branding and SEO)
purposes and tighter constraints to enforce partitioning.