When you do a CIFS mount of the AVM, and you look at the top-level
directories you might see a bunch of directories ike this:
mysite
mysite–admin
mysite–alice
mysite–bob
Each of these directories corresponds to a *store* within the AVM,
not a sandbox. A sandbox is a collection of stores. Each store
(aka: "virtual repository") is very much like a Subversion (SVN)
repository, only you can overlay them using a mechanism called
"transparency". Clickhere to see why this is useful.
When each user works in their own sandbox, they all enjoy the ability
to isolate their development environment (e.g.: what files are changed)
from everyone else's. The reason why sandboxes include both a
"main" working store, and a "preview" store is so that templating
operations can be "previewed" without clobbering any of the
precious data in the main working store of the user's sandbox.
If you like what you "preview", you can accept it; otherwise, you
can toss it away and be confidant that *nothing* in your main workarea
has been altered.
Just as the store used for the author's main workarea is overlay on
your web project's staging store, ephemeral "preview" data is sent
to a store that's an overlay on the author's main workarea.
A triple-decker tranparent sandwich, if you will.
Just as a sandbox is a higher-level structure of AVM content stores
bound together by metadata & workflows, a web project is
an even higher-level structure of sandboxes bound together by
metadata & workflows too. A web project is the high-level object
corresponds to *all* the various areas & objects used to create
a multi-user collaborative environment devoted to building a website.
Suppose you do a directory listing in CIFS, and you see something like:
mysite
mysite–admin
mysite–alice
mysite–bob
Or even:
mysite
mysite–preview
mysite–admin
mysite–admin–preview
mysite–alice
mysite–alice–preview
mysite–bob
mysite–bob–preview
What you're seeing here are stores (low-level virtual repositories)
within the AVM. The default naming scheme of these stores gives
you a very good idea of how things are organized under the hood
(unless someone has renamed them).
For example, all these stores probably belong to the web project
named "mysite". Within the "mysite" web project the user Alice
has a sandbox that consists of two stores: mysite–alice and
mysite–alice–preview. Note that the mysite project also
has a sandbox for bob & admin. The "staging area" of the
mysite project contained within a store named "mysite"; note also
that there's yet another store called "mysite–preview" in case you
want to do fancy stuff later like deferring the final promotion of
submitted content to the main staging area. Currently, all sandboxes
in Alfresco consist of just 2 stores (it's "main" store and the scratch
"preview" store), but this is something that will probably be made
more flexible & tunable later on. As things stand, the CIFS projection
avoids showing you *all* the stores by default… it omits showing you
most of the "preview" stores because people typically don't want the
visual clutter of seeing directories that just contain ephemeral/scratch
data.
Another interesting thing to note is that the leading portion of the
default DNS name corresponding to each store follows a very similar
scheme to the one used by CIFS, only the order is reversed.
For example, the URL for the main working store of Alice's sandbox
looks like:
alice.mysite.www–sandbox.<virt-domain>:<port>/…
By making the CIFS name for this store look like "mysite–alice"
the users of the file system get to see the "real" store names
and everything lines up nicely when you do a directory listing
(and works nicely with tab-completion). File systems are organized
from least specific to most specific, so this makes perfect sense.
However, DNS is organized the opposite way: from most to least specific.
Thus, in order for stuff like wildcard cookies, wildcard X.509 certs, etc
to work properly, "alice" is a subdomain of "mysite". Similarly, when
you're previewing ephemeral "what if" data in templating, your url
will look like this:
preview.alice.mysite.www–sandbox.<virt-domain>:<port>/…
By default, that will correspond to the mysite–alice–preview store.
I'm glossing over several important details here because the *real*
associations are determined by metadata values associated with
the stores, not by the store names. However, if you don't go around
changing the naming scheme by renaming stores, the simplified
description I've provided above holds. Relying on metadata
is more robust because it allows us to do store renaming
(if/when necessary), and still have all the workflow & webapp logic
dealing with stores, sandboxes and web projects work.
I'm not sure if you wanted this level of detail, or if you were looking
for a 2-sentence overview, but hopefully I've covered things in a
way that has answered the question you've asked (or were about to).
Cheers,
-Jon
directories you might see a bunch of directories ike this:
mysite
mysite–admin
mysite–alice
mysite–bob
Each of these directories corresponds to a *store* within the AVM,
not a sandbox. A sandbox is a collection of stores. Each store
(aka: "virtual repository") is very much like a Subversion (SVN)
repository, only you can overlay them using a mechanism called
"transparency". Clickhere to see why this is useful.
When each user works in their own sandbox, they all enjoy the ability
to isolate their development environment (e.g.: what files are changed)
from everyone else's. The reason why sandboxes include both a
"main" working store, and a "preview" store is so that templating
operations can be "previewed" without clobbering any of the
precious data in the main working store of the user's sandbox.
If you like what you "preview", you can accept it; otherwise, you
can toss it away and be confidant that *nothing* in your main workarea
has been altered.
Just as the store used for the author's main workarea is overlay on
your web project's staging store, ephemeral "preview" data is sent
to a store that's an overlay on the author's main workarea.
A triple-decker tranparent sandwich, if you will.
Just as a sandbox is a higher-level structure of AVM content stores
bound together by metadata & workflows, a web project is
an even higher-level structure of sandboxes bound together by
metadata & workflows too. A web project is the high-level object
corresponds to *all* the various areas & objects used to create
a multi-user collaborative environment devoted to building a website.
Suppose you do a directory listing in CIFS, and you see something like:
mysite
mysite–admin
mysite–alice
mysite–bob
Or even:
mysite
mysite–preview
mysite–admin
mysite–admin–preview
mysite–alice
mysite–alice–preview
mysite–bob
mysite–bob–preview
What you're seeing here are stores (low-level virtual repositories)
within the AVM. The default naming scheme of these stores gives
you a very good idea of how things are organized under the hood
(unless someone has renamed them).
For example, all these stores probably belong to the web project
named "mysite". Within the "mysite" web project the user Alice
has a sandbox that consists of two stores: mysite–alice and
mysite–alice–preview. Note that the mysite project also
has a sandbox for bob & admin. The "staging area" of the
mysite project contained within a store named "mysite"; note also
that there's yet another store called "mysite–preview" in case you
want to do fancy stuff later like deferring the final promotion of
submitted content to the main staging area. Currently, all sandboxes
in Alfresco consist of just 2 stores (it's "main" store and the scratch
"preview" store), but this is something that will probably be made
more flexible & tunable later on. As things stand, the CIFS projection
avoids showing you *all* the stores by default… it omits showing you
most of the "preview" stores because people typically don't want the
visual clutter of seeing directories that just contain ephemeral/scratch
data.
Another interesting thing to note is that the leading portion of the
default DNS name corresponding to each store follows a very similar
scheme to the one used by CIFS, only the order is reversed.
For example, the URL for the main working store of Alice's sandbox
looks like:
alice.mysite.www–sandbox.<virt-domain>:<port>/…
By making the CIFS name for this store look like "mysite–alice"
the users of the file system get to see the "real" store names
and everything lines up nicely when you do a directory listing
(and works nicely with tab-completion). File systems are organized
from least specific to most specific, so this makes perfect sense.
However, DNS is organized the opposite way: from most to least specific.
Thus, in order for stuff like wildcard cookies, wildcard X.509 certs, etc
to work properly, "alice" is a subdomain of "mysite". Similarly, when
you're previewing ephemeral "what if" data in templating, your url
will look like this:
preview.alice.mysite.www–sandbox.<virt-domain>:<port>/…
By default, that will correspond to the mysite–alice–preview store.
I'm glossing over several important details here because the *real*
associations are determined by metadata values associated with
the stores, not by the store names. However, if you don't go around
changing the naming scheme by renaming stores, the simplified
description I've provided above holds. Relying on metadata
is more robust because it allows us to do store renaming
(if/when necessary), and still have all the workflow & webapp logic
dealing with stores, sandboxes and web projects work.
I'm not sure if you wanted this level of detail, or if you were looking
for a 2-sentence overview, but hopefully I've covered things in a
way that has answered the question you've asked (or were about to).
Cheers,
-Jon
