[haiku-web] Re: Trac migration to AccountManager

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: