On Tue, 2006-03-21 at 09:09 -0800, Allen Gilliland wrote: > 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.
It's true that this would benefit only a small number of users, existing users anyway. But this might open the door for new ones. And I assure you that our intentions is to modify or rewrite as little of the existing codebase as possible. > 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. We will definitely make this optional. We fully understand, and agree, that it is a bad idea to force a domain centric approach on users who only have one server, and have no need for this approach. Our plan is to make this configurable either through a property-file or through the administrators interface. > 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. We have to make this change either way, so we will just have to live with this.. :) But any info we can get about this, so we know what changes to avoid, would surely help. > 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. I understand that. We will try our best not to break anything. Our approach, as it looks now, will be to make as few changes to the existing code base as possible. Firstly because we will have to maintain a patch if we can't get this accepted upstream, and the less changes we make, the easier it will be to maintain this patch. And secondly because we believe it will be easier for you to accept a patch if it doesn't change to much of the existing functionality. > > 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 > > > -- Regards, Henning Kulander System consultant Linpro AS - Norway's #1 Linux company
