[haiku-web] Re: Trac migration to AccountManager
- From: "Niels Reedijk" <niels.reedijk@xxxxxxxxx>
- To: haiku-web@xxxxxxxxxxxxx
- Date: Wed, 9 Apr 2008 22:48:13 +0200
Hi Jorge,
2008/4/9, Jorge G. Mare <koki@xxxxxxxxxxxxxx>:
> 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.
Yes. I agree. But then again, installing a third system between those
two, to act as a mediator, with known and published protocols (such as
OpenID), will not be less reliable, and will provide a future upgrade
path.
> 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.
Well, thanks for your concerns, but I do not really feel 'caught in
between'. A few weeks back (time flies) I had implemented the other
solution to keep the current connection. I don't really mind. I think
keeping all options open is good at this point.
> 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).
Well, I think we are hitting a common Open Source problem. Who decides
what? Especially with the infrastructure, that can be a problem. I do
not feel that Axel is vetoing this option, but at the same time, I
also do not feel like this choice is a done deal yet. It might be
interesting discussing the merits and problems a bit more before we
dive in a decision.
N.
�����~���+-��� ���g�
�ޖ�^�+����+ ��"�r��
Other related posts:
