Hi Allen
I strongly see and understand the reasons behind your concerns.
Let me try to explain a bit more about how we are thinking. We have spent a
lot of time evaluating (almost one year now) different blog software and we
also have one installation of your largest competitors running (Drupal,
which we are not happy with) as an pilot and we have found Roller to be way
ahead of all other blog solutions out there when it comes to technical
architecture. But, no blog solution has this multi domain support. I think
such a support would be a benefit for a whole new set of Roller users (and
possible contributors).
In our organization we have to deal with the problem of several domains at
one server-park similar to my first explanation and we will (we have to) be
running this on about 50 domains to begin with, but the reality it that this
will probably grow to about the double in the near future. So; we have to
develop some kind of multi domain support in Roller to be able to host this.
We have no other choice and I wish we had
We approach this multi domain development whit the intention that its not
going to be provided back to the Roller community and find its way into the
Roller code. We must take this approach because the decision of submitting
it into the core Roller code is not ours. Thats up to you to decide and we
must be prepared to get a no on our proposal.
But; we would be happy to contribute the work we do back to the community.
By having this approach we face several challenges and the main challenge is
that we will not be in a situation where we must do a lot of changes in our
custom code to Roller if we do not get it submitted back to the project. To
be in a situation where we must maintain and do a lot of changes in a custom
code to Roller for each official Roller release is not a pleasant situation
to be in. Especially when it comes to security issues this is not a pleasant
situation.
We will try to avoid touching Roller core code as far as possible because
this will decrease the level of code we have to maintain for each Roller
release if the project does not want to incorporate a multi domain support
as a core feature.
Another benefit by trying to not to touch the Roller core code with this
multi domain support is that it can be provided as a plug-in or expansion
to Roller for those who need such a support. Single domain installations
would perhaps not even need to download this support.
In other words; it is also in our interest to make this an optional feature.
But; the reality is that this might go deep into the core code. In these
cases we will approach the challenge by trying to make changes which extend
the Roller code so it will be possible to build such a multi domain feature
as an optional feature.
Our intention is to try to make this an optional (due to maintain reasons)
feature and we would be very happy to contribute this back to the project.
To begin with we need to solve the challenges we face regarding hosting this
on multi domains, but when we have this sorted out we would be very happy to
contribute to fix bugs and create new and more common features in Roller.
Our intention is to develop a proposal (and source code based on the
proposal) which make this multi domain support as an optional feature and
which will interfere with the core code of Roller as little as possible.
Kind regards
Trygve Lie
From: Allen Gilliland <[EMAIL PROTECTED]>
Reply-To: roller-dev@incubator.apache.org
To: "roller-dev@incubator.apache.org" <roller-dev@incubator.apache.org>
Subject: Re: Multi domain support in Roller
Date: Tue, 21 Mar 2006 09:09:07 -0800
I would just like to voice a few concerns I have about this idea ...
1. You are proposing to modify/rewrite a very large portion of the
codebase and introduce significant complexity to the application for a
feature that I believe most Roller users will get zero benefit from.
For this reason I would say you are likely to get some pushing from me
as far as commiting this to the Roller repository.
It's not that I don't think your idea is a valid and useful one, but I
am concerned that you are proposing something that really only benefits
a very small number of users.
2. The changes you are proposing would not be optional, so you would be
forcing everyone into your domain centric approach. This may or may not
be a good thing, but none the less it will make things harder to
swallow. The more mandatory changes you make the more scared I get.
3. As far as timing goes I just want to let you know that Dave and I are
planning some fairly significant changes to Roller over the next 3-4
months. The biggest changes will likely come around early summer in
Roller 3.0 and will include a completely redesigned url structure and a
number of changes to how the front page will work.
I don't want to discourage you from doing your work, but I wanted to
give you early notice about these changes so that you aren't suprised by
them. The url changes that we will be making will certainly cause some
conflicts with any work that you do now against the 2.x codebase.
I hate to sound like a worry wart, but the fact is that we run a very
large Roller site and we would have no use for this feature, so it's
hard for me to want to make such a large change when it doesn't add any
value to my site.
-- Allen
On Tue, 2006-03-21 at 05:29, Henning Kulander wrote:
> On Fri, 2006-03-17 at 11:19 -0500, David M Johnson wrote:
> > On Mar 16, 2006, at 9:33 AM, Henning Kulander wrote:
> > > 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,
> >
> > Are you sure you want to use pathinfo to partition domains? The
> > previous email seemed to indicate that you'd use (virtual?) domain
> > names to indicate different sites.
>
> The reason for using pathinfo is to most easily fit into the existing
> model. URL-rewriting will then be used to map the virtual domains to
> paths in Roller.
>
> > > 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).
> >
> > Sounds like the beginning of a reasonable plan. Note that we are
> > working on some proposals for changing the Roller URL structure (not
> > yet on wiki) and the way the front pages works.
>
> Do you have more info on that?
>
> > > 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!
> >
> > I outlined a plan for doing this in my response to Trygve.
>
> When we get access to the Wiki, we will put up a proposal there. We are
> getting valuable feedback here that we will use in the proposal.
> Currently I am doing some experiments with the code to see if this will
> work.
>
>
> --
> Regards,
> Henning Kulander
> System consultant
> Linpro AS - Norway's #1 Linux company
>
_________________________________________________________________
MSN Music http://music.msn.no Finn din favorittmusikk blant nesten 1 million
låter
