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
