[haiku-web] Re: Trac migration to AccountManager
- From: "Jorge G. Mare" <koki@xxxxxxxxxxxxxx>
- To: haiku-web@xxxxxxxxxxxxx
- Date: Wed, 09 Apr 2008 13:21:40 -0700
Hi Axel,
On Wed, 2008-04-09 at 20:51 +0200, Axel Dörfler wrote:
> "Curtis Wanner" <katisu@xxxxxxxxxxx> wrote:
> > Axel wrote:
> > > Not sure if I understand what you're saying, but in the long run,
> > > if we
> > > intend to keep our user databases separate, we definitely should
> > > have
> > > some mechanism to synchronize them automatically from time to time.
> > Well, this is the issue. If they are located on separate servers, do
> > we
> > really want Trac to depend on the other server being up and
> > accessible? Do
> > we really want to swap user data back and forth over the internet?
> > Do we
> > really want to rely on a mechanism that will likely be broken with an
> > upgrade in software? All this so that someone doesn't have to take a
> > few
> > seconds to register?
>
> Yes, I do want that. If the databases are mirrored on different
> servers, there is no dependency. You need to swap user data over the
> internet anyway, it doesn't matter between which server that happens.
> And the only way to make something really reliable, is by making it
> redundant, not separate, anyway.
> I don't quite see why this mechanism will likely be broken by a
> software update either - it *might* need a little love with every major
> update (every two years or so??), but that doesn't sound like ooh so
> much work to me.
If Trac on server A needs to access the DB of the website on server
B, there are certain situations that can break or affect Trac
functionality, such as when server B is down, or when the DB in server B
is down. This setup also requires making changes on one system when the
other is moved to different a server (which can/will happen). It also
means that any customization(s) required by this setup be migrated when
systems are upgraded; this may be trivial or not, but you can never know
(as we do not know what/how Trac and/or Drupal will change in the
future).
These are the sort of dependencies that we want to avoid.
Maintaining the present interdependent system during upgrades or server
moves may not sound like a lot of work, and that may be the case as long
as the person who does the customizations is around and has the time and
inclination to take care of things. But as we already know, this is
never guaranteed to be the case in open source. So we are simply taking
the practical approach.
Finally, I feel sorry for Niels being caught in between what was long
ago discussed/agreed by consensus on this list and what looks like your
veto against this decision after all this time.
Which is why I would ask again if you could please show some
flexibility, and went along with our decision even if you disagreed
with it (which we can understand).
Cheers,
Koki
-----------------------------------------------------------------------
haiku-web@xxxxxxxxxxxxx - Haiku Web & Developer Support Discussion List
Other related posts:
