Dmitry Yemanov wrote:

> Jim Starkey wrote:
>
>>
>> What you're saying is that if you go out of your way to screw it up, you
>> can screw it up.
>>
>
> Nope, I say that the default setup is screwed up. Do you see the
> difference between: "you can change something to break the thing" and
> "you must change something to avoid shit from happening"?
>

The "factory default" parameters should be set in a per-provider
configuration file included by the server master configuration file. As
designed, the configuration files are laid out so that some are
controlled by the user and left unchanged by installations while others
are intended to be replaced or extended by subsequent installations.
There's nothing to say that either future developers will continue to
honor the conventions or that some users won't find a compelling reason
to subvert the convention. But, at it stands, a per-provider
configuration should be provided by the installation. But I agree, if
someone wants to hand tailor two incompatible engines to use the same
lock table, it won't work. I hope, however, that the second engine to
attach to the lock table will notice an incompatible lock table format
version and give a polite error message (hint: If there isn't one now,
this a good time to add one).

>
>> There is no reason for a user to change the lock file name from whatever
>> the installation configures. And if the installation configures
>> different lock files for incompatible engines, then it works.
>>
>
> But we don't have any installation at all at the moment, so your words
> sound like: yes, I've screwed up the thing, but a clever installation
> routine (that I didn't care to implement or even document) should solve
> that.
>

Ah, so the problem isn't with the design, but that you personally don't
want to make it work. That's quite a different problem, and a problem
that can't be address in software design.

> Also, you haven't answered what the installation should do with
> fb_lock_print.
>

I presume anyone desiring to have multiple installations co-exist (which
is everyone during transition) will discover a neat feature of modern
operating system -- the directory! It turns out that with different
directories, you can have files of the same name on the same computer!
So, rather than overlaying the previous version, an installation could
put the installation executables in a distinct directories. Since just
about every major software system does this, you can probably find a
couple of models to follow...

>
>>
> Why do you take any critique of the implementation as a personal attack
> to your lovely architecture? The point of my message was not to say that
> the architecture is crap but to show that it exposes some issues that
> requires solving. You could manage to screw up the FB setup the same
> way, but it would never happen in the default mode, be it done via the
> automatic installer or manual unzipping. This is what I'd like to see in
> Vulcan. If you cannot suggest anything useful, then I'll be treating the
> feature as potentially dangerous.
>
>

No, I just take offense at the attitude of "I don't understand it, let's
kill it" which, I understand, you are also arguing about buildgen on
another list.

I'm quite sorry that you are only willing to consider useful comments
from me. There are many other folks on the project whose comments
should be heard, too.

>> Rather than just giving us your opinion, why don't you critique the
>> design. Is there something it doesn't do that it should? Can it be
>> extended? Do we understand how it should be administrated? Or you
>> might just hint at what you don't like.
>>
>
> I've posted a problem and asked for solutions. You answered that
> everything is as designed and nothing should be changed. I'm not
> satisfied, sorry. Suggestion of Rick Debay sounds more constructive and
> friendly, although it doesn't address the fb_lock_print issue. Also, the
> events table has the same problem (although, fortunately, its version is
> not changed often).
>
>
>

I never said that nothing should be changed. I never said that about
anything. I said that the issue was considered and addressed in the
design so it wasn't necessary to trash the configuration file system.

Why don't you restart the discussion in a more reasonable mode. Say,
"OK, folks, let's look at the problems and potential solutions for
addressing version co-existence for future installations."