Multi domain support in Roller

Hi Henning,

I faced the same requirement in customizing Roller for one
of my  
clients. We had to work with Roller 1.x codebase (which was
the  
latest release at the time) and it had fairly different data
model.  
However, I think you will face many of the same issues. The
approach  
we took was to encode domain in username itself and used  
UrlRewriteFilter to translate /page/domain/user URL into
/page/ 
domain_user -- very similar to what you described.

I have a few thoughts on your proposal:

1) It would be nice to be able to have the same usernames
and website  
handles in different domains. Association tables are fine to
assign  
users/websites to domain but they won't help with Roller
expecting  
username and handle to be unique. Ideal solution would be to
add  
extra attribute to UserData and WebsiteData POJOs.

2) You will also need to deal with domain-segmenting search.
Again,  
modifying core code to store an extra attribute in Lucene
index  
should do the trick.

3) If you want to allow same usernames in different domains
file  
upload will need to change in order to handle that. Right
now, files  
are stored in sub-directories named after usernames so there
could be  
conflict.

Since this is something I find very useful as well, I
volunteer to  
help with development.

Max



On Mar 16, 2006, at 9:33 AM, Henning Kulander wrote:

> Hi!
>
> I'm one of the developers hired to implement the blogs
for Trygve Lie.
> As he mentioned in his post, one of our requirements is
to set up one
> blog server for several (say 50) domains, with separate
look and feel,
> and separate blogs and users. One way to do this is of
course to  
> install
> 50 roller servers with 50 database instances. But this
would require a
> lot of database connections that are not shared, and a
lot of extra
> overhead for caching 50 different Roller servers etc.
>
> Instead we plan to extend Roller with an optional
multi-domain  
> mode. We
> are still planning how we can accomplish this, but we
now have some
> ideas. One of our goals is to get our patches accepted
in the official
> Roller source. We want to do this because we want to
give something  
> back
> to the Roller community, and we believe more companies
will need this
> feature. Another reason is that we don't want to
maintain a  
> separate set
> of patches we need to apply to all future versions of
Roller before we
> put them in production. To ensure that we make the
changes in a  
> fashion
> compatible with the rest of the Roller-community, we
are now asking  
> for
> feedback and ideas before we start implementing
changes.
>
> What's needed here is a way to group
"rolleruser"s and "website"s in
> domains so they can be controlled by domain
administrators. The domain
> administrator also needs to be able to control default
themes and
> available themes for one domain. (ie. blog.comany1.no
has a default
> theme with the Company1-logo at the top,
blog.company2.no has a
> different default theme, and the company1-theme is not
available).
>
> One way to do this might be to add some extra tables to
the database
> describing the domain. The table will contain name,
description,  
> domain
> settings etc. When a user is added to a domain, a
connection between
> rolleruser and domain is created in a new table called
domainuser.  
> When
> a website is added to a domain, a connection between
website and  
> domain
> is created in a table called domainwebsite to show that
a website is
> part of that domain (ie. a user can exist in more than
one domain, and
> so can a website). The names of the tables are not
final yet.
>
> The normal behavior in Roller should be left as it is
now, but the
> administrator is given an option to turn on
multidomain-mode. When  
> this
> is enabled, the administrator can add new domains, and
add an
> administrator-user to that domain. Existing websites
and users will
> continue to exist as before under roller/page/sitename,
what's new  
> here
> is a new configuration where a domain administrator can
add users,
> wesites and set configuration for the domain. This
could be put under
> roller/domain/domainname for example. This level would
also have
> functionality like the front page for roller, but would
only contain
> blogs from this domain, a planet uniqe for this domain,
and optionally
> the ability for a user to register for this domain
only. (in the
> background, the user would also be registered as a
global rolleruser,
> but the global site could be filtered out so this would
be transparent
> for users).
>
> To make the sentral server invisible to the end user,
the URLs must be
> filtered and rewritten so blog.company1.no is
translated to
> bigblog.no/roller/domain/company1, and
blog.company1.no/blogname is
> translated to bigblog.no/roller/page/blogname etc. This
functionality
> should be done by mod_rewrite or a UrlRewriteFilter and
be kept out of
> Roller, but should be possible and documented to allow
others to do  
> the
> same.
>
> What we need now is some feedback on what mistakes we
are likely to  
> make
> here, and how you would like us to proceed so we can
get patches
> upstream and not break your incredible application.
Ideas on how to do
> this would certainly help!
>
>
> --
> Regards,
> Henning Kulander
> Systems consultant
> Linpro AS - Norway's #1 Linux company
>

Hi Max!

This is excellent news! I certainly hope we can learn from
your
experiences when we implement this.

I have written replies to your thoughts bellow. Hopefully we
can find a
solution that can serve all needs, both ours, yours and
other Roller
users. 

On Tue, 2006-03-21 at 02:58 -0500, Max Rudman wrote:
> I faced the same requirement in customizing Roller for
one of my  
> clients. We had to work with Roller 1.x codebase (which
was the  
> latest release at the time) and it had fairly different
data model.  
> However, I think you will face many of the same issues.
The approach  
> we took was to encode domain in username itself and
used  
> UrlRewriteFilter to translate /page/domain/user URL
into /page/ 
> domain_user -- very similar to what you described.
> 
> I have a few thoughts on your proposal:
> 
> 1) It would be nice to be able to have the same
usernames and website  
> handles in different domains. Association tables are
fine to assign  
> users/websites to domain but they won't help with
Roller expecting  
> username and handle to be unique. Ideal solution would
be to add  
> extra attribute to UserData and WebsiteData POJOs.

We actually se it as a benefit that the username is unique
across
domains. In this way we can have one user profile available
on more than
one domain. We want to do the same with websites, so one
blogger can
have his blog available on several domains, and maybe have a
special
blog on only one of the domains. 

This is functionality we will probably not implement in the
first
version, but we have to plan for it now. In the final
version, we
imagine a system where a user can register on one domain,
using his
email as username, and the system will automatically see
that this user
is registered in the central Roller-system. The user is
asked to
authenticate using his password, and if that matches, the
Roller-user is
associated with the current domain. The user is than given a
choice to
make one or more of his existing blogs available on the
current domain,
or to create a new one. 

This will solve the problem (for us at least) of unique
usernames. But
handles are still a problem. Given that we need cross-domain
websites
and that handles like "info",
"news", "football" etc. probably
should be
able to exist in more than one domain, and contain different
information, we will probably need to have a handle that is
unique to
the domain in addition to a unique handle in Global Roller. 

So my suggestion here is to keep the existing handle in
website, and add
a domain-handle in the association table between domain and
website
(domainwebsite). So when a user request /page/handle, the
handle in
website is used, when the user requests /page/domain/handle,
the handle
in domainwebsite is used, this could be the same website,
but it could
also be a completely different website. In the same
fashion, /page/domain2/handle could be the same website, but
it could be
a different if the domainwebsite with
handle.equals("handle") and
domain.equals("domain") points to another
website. 

The difficulty now is to ensure that when a user creates a
website on a
domain with a handle, the Roller application needs to create
a unique
handle in the Global website table. This could be
"handle", "handle1",
"handle2" etc. like hotmail usernames..  Or we
could simply append the
domain name where the website was created if it is not
unique, so the
first website with "handle" as handle would get
"handle" in website, the
second would get "handle_domain2" in website,
and "handle" in
domainwebsite. 

This model could also be applied to usernames, so a domain
username is
stored in domainuser, the association table between
rolleruser and
domain. Maybe it could be made optional? if (
allow_uniuque_usernames )
{ use domainuser.username } else { use rolleruser.username }

How does this fit with your needs?
Am I heading for a minefield here? 

> 2) You will also need to deal with domain-segmenting
search. Again,  
> modifying core code to store an extra attribute in
Lucene index  
> should do the trick.

I had completely forgotten this. Did you solve this in your
version?
This would probably be much the same now, wouldn't it?

> 3) If you want to allow same usernames in different
domains file  
> upload will need to change in order to handle that.
Right now, files  
> are stored in sub-directories named after usernames so
there could be  
> conflict.

Hm... This would not be a problem if the usernames are
unique across
domains as I propose here. If the usernames are not unique,
we would
have to use the username in the rolleruser object instead of
the
domain-specific username. 

> Since this is something I find very useful as well, I
volunteer to  
> help with development.

Excellent! Do you have any idea how much of your existing
code we could
reuse? Did you make administration interfaces for this as
well?  What
about documentation, do you have anything we could take a
peek at?

> On Mar 16, 2006, at 9:33 AM, Henning Kulander wrote:
> 
> > Hi!
> >
> > I'm one of the developers hired to implement the
blogs for Trygve Lie.
> > As he mentioned in his post, one of our
requirements is to set up one
> > blog server for several (say 50) domains, with
separate look and feel,
> > and separate blogs and users. One way to do this
is of course to  
> > install
> > 50 roller servers with 50 database instances. But
this would require a
> > lot of database connections that are not shared,
and a lot of extra
> > overhead for caching 50 different Roller servers
etc.
> >
> > Instead we plan to extend Roller with an optional
multi-domain  
> > mode. We
> > are still planning how we can accomplish this, but
we now have some
> > ideas. One of our goals is to get our patches
accepted in the official
> > Roller source. We want to do this because we want
to give something  
> > back
> > to the Roller community, and we believe more
companies will need this
> > feature. Another reason is that we don't want to
maintain a  
> > separate set
> > of patches we need to apply to all future versions
of Roller before we
> > put them in production. To ensure that we make the
changes in a  
> > fashion
> > compatible with the rest of the Roller-community,
we are now asking  
> > for
> > feedback and ideas before we start implementing
changes.
> >
> > What's needed here is a way to group
"rolleruser"s and "website"s in
> > domains so they can be controlled by domain
administrators. The domain
> > administrator also needs to be able to control
default themes and
> > available themes for one domain. (ie.
blog.comany1.no has a default
> > theme with the Company1-logo at the top,
blog.company2.no has a
> > different default theme, and the company1-theme is
not available).
> >
> > One way to do this might be to add some extra
tables to the database
> > describing the domain. The table will contain
name, description,  
> > domain
> > settings etc. When a user is added to a domain, a
connection between
> > rolleruser and domain is created in a new table
called domainuser.  
> > When
> > a website is added to a domain, a connection
between website and  
> > domain
> > is created in a table called domainwebsite to show
that a website is
> > part of that domain (ie. a user can exist in more
than one domain, and
> > so can a website). The names of the tables are not
final yet.
> >
> > The normal behavior in Roller should be left as it
is now, but the
> > administrator is given an option to turn on
multidomain-mode. When  
> > this
> > is enabled, the administrator can add new domains,
and add an
> > administrator-user to that domain. Existing
websites and users will
> > continue to exist as before under
roller/page/sitename, what's new  
> > here
> > is a new configuration where a domain
administrator can add users,
> > wesites and set configuration for the domain. This
could be put under
> > roller/domain/domainname for example. This level
would also have
> > functionality like the front page for roller, but
would only contain
> > blogs from this domain, a planet uniqe for this
domain, and optionally
> > the ability for a user to register for this domain
only. (in the
> > background, the user would also be registered as a
global rolleruser,
> > but the global site could be filtered out so this
would be transparent
> > for users).
> >
> > To make the sentral server invisible to the end
user, the URLs must be
> > filtered and rewritten so blog.company1.no is
translated to
> > bigblog.no/roller/domain/company1, and
blog.company1.no/blogname is
> > translated to bigblog.no/roller/page/blogname etc.
This functionality
> > should be done by mod_rewrite or a
UrlRewriteFilter and be kept out of
> > Roller, but should be possible and documented to
allow others to do  
> > the
> > same.
> >
> > What we need now is some feedback on what mistakes
we are likely to  
> > make
> > here, and how you would like us to proceed so we
can get patches
> > upstream and not break your incredible
application. Ideas on how to do
> > this would certainly help!
> >
> >
> > --
> > Regards,
> > Henning Kulander
> > Systems consultant
> > Linpro AS - Norway's #1 Linux company
> >
> 
-- 
Regards,
Henning Kulander
System consultant
Linpro AS - Norway's #1 Linux company

Answers/comments below....

On Mar 21, 2006, at 7:45 AM, Henning Kulander wrote:

>  In the final version, we
> imagine a system where a user can register on one
domain, using his
> email as username, and the system will automatically
see that this  
> user
> is registered in the central Roller-system.

Well, if you are using email address as username you are in
essence  
encoding domain in the username (the part after ). It's
not domain  
in DNS sense but same idea. I think that will work just
fine, BTW.  
Again, we did this work on Roller 1.x where there was no
handle --  
username was it.

> So my suggestion here is to keep the existing handle in
website,  
> and add
> a domain-handle in the association table between domain
and website
> (domainwebsite). So when a user request /page/handle,
the handle in
> website is used, when the user requests
/page/domain/handle, the  
> handle
> in domainwebsite is used,

How would this actually work without touching Roller
presentation  
code? If I understand you correctly, '/domain/handle' is a
virtual  
URL which would be rewritten to /page/<handle> format.
Having handle  
spread across two tables would seem to complicate things as
we'd have  
to modify several methods in UserManager to pull it
together. I think  
easier options are to:

1) Prepend domain to website handles, so it becomes
something like  
"domain + <separator> + handle". Set up
URL rewrite rule to redirect / 
domain/handle to /page/domain + <separator> + handle.
The down side  
is we'd have to "decode" the handle everywhere
it appears in the UI  
-- website edit form, URL links, etc.

2) Add new, nullable property to WebsiteData to keep track
of domain.  
All we have to do then is override
UserManager.getWebsiteByHandle 
(String,boolean) to (optionally) add 'domain' to the query
and  
UserManager.createWebsite() to assign domain on creation.

In both cases, I see 'domain' being extracted from URL
and/or request  
parameter and/or session attribute by a filter and stashed
in a  
ThreadLocal variable for use by code down the call stack
such as  
UserManager.

> I had completely forgotten this. Did you solve this in
your version?
> This would probably be much the same now, wouldn't it?

We had to overwrite a few search-related classes. However,
if we add  
'domain' property to WebsiteData it should be literally a
matter of  
adding a new constant to SearchConstants and a few lines to
a couple  
of XXXOperation classes.

> Excellent! Do you have any idea how much of your
existing code we  
> could
> reuse? Did you make administration interfaces for this
as well?  What
> about documentation, do you have anything we could take
a peek at?

Probably not much as it was written to Roller 1.x codebase
which is  
fairly different. In terms of admin interface, do you mean
something  
to manage domains? My job was to integrate Roller into the
existing  
platform which already had UI to manage domains. So, no, I
didn't  
have anything. In terms of documentation, let me talk to my
client  
and see what they feel comfortable disclosing.

Max

On Tue, 2006-03-21 at 17:42 -0500, Max Rudman wrote:
> Answers/comments below....
> 
> On Mar 21, 2006, at 7:45 AM, Henning Kulander wrote:
> 
> >  In the final version, we
> > imagine a system where a user can register on one
domain, using his
> > email as username, and the system will
automatically see that this  
> > user
> > is registered in the central Roller-system.
> 
> Well, if you are using email address as username you
are in essence  
> encoding domain in the username (the part after ). It's
not domain  
> in DNS sense but same idea. I think that will work just
fine, BTW.  
> Again, we did this work on Roller 1.x where there was
no handle --  
> username was it.

Well, the email here cannot be used to map to a specific
domain, as the
email will be an existing address, not necessarily related
to the blog
domain (for example an existing gmail.com address). 

> > So my suggestion here is to keep the existing
handle in website,  
> > and add
> > a domain-handle in the association table between
domain and website
> > (domainwebsite). So when a user request
/page/handle, the handle in
> > website is used, when the user requests
/page/domain/handle, the  
> > handle
> > in domainwebsite is used,
> 
> How would this actually work without touching Roller
presentation  
> code? If I understand you correctly, '/domain/handle'
is a virtual  
> URL which would be rewritten to /page/<handle>
format. Having handle  
> spread across two tables would seem to complicate
things as we'd have  
> to modify several methods in UserManager to pull it
together. I think  
> easier options are to:

You're right, in my design, we will need a different
presentation mode
that is aware of the domain model. I have experimented with
making a
DomainPageServlet as a subclass of PageServlet, and make
this answer
to /domain/page, and then having /mydomain/myhandle as a key
to finding
the right website. This seems to work, but the links on the
page all go
back to the original roller website in /page/mywebsitehandle


The changes I have made this far does not affect the way
Roller works
per default, I have only added new classes (DomainData,
DomainWebsiteData and DomainUserData) and subclasses for
PageServlet and
RollerRequest. 

> 1) Prepend domain to website handles, so it becomes
something like  
> "domain + <separator> + handle". Set
up URL rewrite rule to redirect / 
> domain/handle to /page/domain + <separator> +
handle. The down side  
> is we'd have to "decode" the handle
everywhere it appears in the UI  
> -- website edit form, URL links, etc.
> 
> 2) Add new, nullable property to WebsiteData to keep
track of domain.  
> All we have to do then is override
UserManager.getWebsiteByHandle 
> (String,boolean) to (optionally) add 'domain' to the
query and  
> UserManager.createWebsite() to assign domain on
creation.
> 
> In both cases, I see 'domain' being extracted from
URL and/or request  
> parameter and/or session attribute by a filter and
stashed in a  
> ThreadLocal variable for use by code down the call
stack such as  
> UserManager.

The problem I se with this approach is that it is not
possible to have
the same website available on more than one domain, this is
a feature we
will need. One blogger must be able to write an entry in one
blog, and
have that entry appear on several domains, and maybe even
with different
handles on different domains. So page/theboss is the same
blog as
domain/page/blog.domain1.no/sjefblogg and
domain/page/blog.domain2.com/companyleader. 

> > I had completely forgotten this. Did you solve
this in your version?
> > This would probably be much the same now,
wouldn't it?
> 
> We had to overwrite a few search-related classes.
However, if we add  
> 'domain' property to WebsiteData it should be
literally a matter of  
> adding a new constant to SearchConstants and a few
lines to a couple  
> of XXXOperation classes.

Was this how you solved this problem the last time?

> > Excellent! Do you have any idea how much of your
existing code we  
> > could
> > reuse? Did you make administration interfaces for
this as well?  What
> > about documentation, do you have anything we could
take a peek at?
> 
> Probably not much as it was written to Roller 1.x
codebase which is  
> fairly different. In terms of admin interface, do you
mean something  
> to manage domains? My job was to integrate Roller into
the existing  
> platform which already had UI to manage domains. So,
no, I didn't  
> have anything. In terms of documentation, let me talk
to my client  
> and see what they feel comfortable disclosing.

OK. The way I see it, we will need the following new
administration
interfaces:
1. An interface where the Roller-administrator can
enable/dissable
domain support, and add/remove domains and set
administrators for the
domains.
2. An interface where a domain-administrator can add users
and websites
to a domain and set which themes should be available etc. 
3. An interface where a user can select on what domains one
of his
websites should be available. The user should also be able
to select
theme, handle and maybe some other settings per domain. 
4. An interface where a domain-administrator can add
subscriptions to a
domain planet. 


-- 
Regards,
Henning Kulander
System consultant
Linpro AS - Norway's #1 Linux company

On Mar 23, 2006, at 11:02 AM, Henning Kulander wrote:

>> Well, if you are using email address as username
you are in essence
>> encoding domain in the username (the part after
).
It's not domain
>> in DNS sense but same idea. I think that will work
just fine, BTW.
>> Again, we did this work on Roller 1.x where there
was no handle --
>> username was it.
>
> Well, the email here cannot be used to map to a
specific domain, as  
> the
> email will be an existing address, not necessarily
related to the blog
> domain (for example an existing gmail.com address).

I was not necessarily suggesting you use email address. I
was  
referring to the general idea of encoding domain in the
username to  
allow users with the same username in different domains.

>> How would this actually work without touching
Roller presentation
>> code? If I understand you correctly,
'/domain/handle' is a virtual
>> URL which would be rewritten to
/page/<handle> format. Having handle
>> spread across two tables would seem to complicate
things as we'd have
>> to modify several methods in UserManager to pull it
together. I think
>> easier options are to:
>
> You're right, in my design, we will need a different
presentation mode
> that is aware of the domain model. I have experimented
with making a
> DomainPageServlet as a subclass of PageServlet, and
make this answer
> to /domain/page, and then having /mydomain/myhandle as
a key to  
> finding
> the right website.

Can you explain a little more why you feel it necessary to
extend  
PageServlet? If its sole purpose is to pass domain to the
business  
logic tier I think using Filter/ThreadLocal approach would
be much  
cleaner.

> This seems to work, but the links on the page all go
> back to the original roller website in
/page/mywebsitehandle

You make a good point here. What we could do here is to
modify  
PageModel view helper class (or extend it) so that current
'domain'  
value is available to Velocity templates. That class is
actually a  
well-known extension point in Roller configurable via  
roller.properties so that should be pretty easy to extend. I
guess  
that means we would also have to go through Velocity macros
to format  
URLs using domain value (if it's not empty, of course). Not
sure the  
extend of that effort.

> The changes I have made this far does not affect the
way Roller works
> per default, I have only added new classes (DomainData,
> DomainWebsiteData and DomainUserData) and subclasses
for  
> PageServlet and
> RollerRequest.

How do you see them being used though? In order for Roller
to use a  
POJO subclass, for example, you would have to modify a ton
of code in  
Manager classes.

>
>> 1) Prepend domain to website handles, so it becomes
something like
>> "domain + <separator> + handle".
Set up URL rewrite rule to  
>> redirect /
>> domain/handle to /page/domain + <separator> +
handle. The down side
>> is we'd have to "decode" the handle
everywhere it appears in the UI
>> -- website edit form, URL links, etc.
>>
>> 2) Add new, nullable property to WebsiteData to
keep track of domain.
>> All we have to do then is override
UserManager.getWebsiteByHandle
>> (String,boolean) to (optionally) add 'domain' to
the query and
>> UserManager.createWebsite() to assign domain on
creation.
>>
>> In both cases, I see 'domain' being extracted
from URL and/or request
>> parameter and/or session attribute by a filter and
stashed in a
>> ThreadLocal variable for use by code down the call
stack such as
>> UserManager.
>
> The problem I se with this approach is that it is not
possible to have
> the same website available on more than one domain,
this is a  
> feature we
> will need. One blogger must be able to write an entry
in one blog, and
> have that entry appear on several domains, and maybe
even with  
> different
> handles on different domains. So page/theboss is the
same blog as
> domain/page/blog.domain1.no/sjefblogg and
> domain/page/blog.domain2.com/companyleader.

We did not have this requirement but I could see how it
would be  
useful. This definitely complicates things as we now also
need a way  
to map a domain handle to the physical blog handle. Could we
maybe  
write a custom URL rewriting filter which could do the
mapping based  
on a database lookup? I just hate messing with Roller
presentation  
code and think we should avoid that as much as possible.

>> We had to overwrite a few search-related classes.
However, if we add
>> 'domain' property to WebsiteData it should be
literally a matter of
>> adding a new constant to SearchConstants and a few
lines to a couple
>> of XXXOperation classes.
>
> Was this how you solved this problem the last time?

Well, we didn't want to touch the original codebase so we
had to copy  
over some code (like SearchServlet) because the methods we
needed to  
override were private. But, essentially, yes, that's how we
did it.  
Basically, it's just the matter of adding domain property
associated  
with each entry to Lucene s and appending it to queries
behind the  
scenes when a search is performed.

> 3. An interface where a user can select on what domains
one of his
> websites should be available. The user should also be
able to select
> theme, handle and maybe some other settings per domain.

My only problem with this is that you are requiring users to
 
explicitly choose which domains their blogs should appear
on. This  
may not always be desirable and in some cases forbidden. For
example,  
an ASP hosting blogs for multiple clients where you
certainly don't  
want any kind of cross-domain publishing and users in
different  
domains should be able to create websites with the same
handle. For  
this reason, I still think it might be better to have
"owner" domain  
assigned to each weblog and use an association table to
"publish"  
that weblog to a different domain under potentially
different handle.

Max

>From: Max Rudman <mrudmansteelbrick.com>
>Reply-To: roller-devincubator.apache.org
>To: roller-devincubator.apache.org
>Subject: Re: Multi domain support in Roller
>Date: Thu, 23 Mar 2006 15:17:08 -0500
>
>>3. An interface where a user can select on what
domains one of his
>>websites should be available. The user should also
be able to select
>>theme, handle and maybe some other settings per
domain.
>
>My only problem with this is that you are requiring
users to  explicitly 
>choose which domains their blogs should appear on. This 
may not always be 
>desirable and in some cases forbidden. For example,  an
ASP hosting blogs 
>for multiple clients where you certainly don't  want
any kind of 
>cross-domain publishing and users in different  domains
should be able to 
>create websites with the same handle. For  this reason,
I still think it 
>might be better to have "owner" domain 
assigned to each weblog and use an 
>association table to "publish"  that weblog
to a different domain under 
>potentially different handle.

I think this should not be a selection a user does. This
should be done at a 
higher lever.
When a blog site is set up, it is set up on a domain which
is a 
configuration the administrator. All users which register
for this domain 
does then only know about this domain. The ordinary user
should not know 
that this is part of a multi domain site.
But there are some blogs which might be awailabe on several
domains. This 
should also be a selection the Administrator does. This is
in tread with our 
requirements and it would also suite an ASP host very well I
think.

Trygve

____________________________________________________________
_____
MSN Web Messenger http://webmess
enger.msn.com/?mkt=nb-no MSN Messenger 
overalt