Hello Jan,

As always I appreciate that you take the time to comment on my messages,
thanks.

On Sun, Aug 03, 2014 at 03:28:16PM -0400, Jan Harkes wrote:
> On Sun, Aug 03, 2014 at 07:03:23PM +0200, u-codalist-z149_at_aetey.se wrote:
> > I had some time to work on the code and here is the result:
> 
> You are working on as far as I am concerned 'a bad color lipstick for
> the pig'. Actual code savings are not likely to be gained in this area,

This first step was not expected to create any savings in code size
(first and foremost because it works around legacy limitations
without actually getting rid of them, to be compatible).

> you will end up with a system where a user will now ask, why do I have a
> dangling symlink to "#105_at_myrealm.org" instead of #user.joe_at_myrealm.org".

The code which handles the mountpoints has not been touched yet.

Nevertheless, taking your description of failure modes:

If there is a dangling link then it doesn't matter what the link looks
like. What matters is that the help desk (otherwise the user herself)
must be able to understand how the mountpoint resolution happens.

#user.joe becomes hanging among others when volume name resolution fails

#105      can not hang for such a reason, hence would be seen more seldom
          and if it is hanging there are fewer possible reasons to analyse

> > The approximate amount of the modifications:
> >  24 files changed, 628 insertions(+), 506 deletions(-)
> 
> In fact you just added an extra 122 lines of code, while leaving several

A large part of this is comments, the rest is the addition
of the endpoints lookup step in the client.

Before this the client used the server ip numbers got from the servers
as-is. Now it does the client-side DNS endpoint resolution - which is
the correct thing.

So this is not a simplification but a plain addition of lacking
functionality. This opens otherwise also for refactoring and
simplification of the rest of the code.

> known broken and a couple of probably broken but untested cases. Don't
> forget to try volume backups and readonly snapshots they may add some
> interesting corner cases too, for instance when an incremental backup
> fails and it destroys the old one, allocates a new volume and then tries
> a full backup.

Up to now no server changes have been done. Unfortunately the server
code needs much more massive changes than the client, to split the
"address" and "identifier" roles assigned to ipv4 addresses.

> As I told you before, you can actually remove quite a bit of very hairy
> code by removing replication, which will also get rid of server-server

Then Coda would become a whole lot less interesting.

My goal is to simplify and clean up as much as possible while keeping the
present virtues. Not like "implementing 70% functionality in 50% code".

> conflicts, resolution, repair, and a host of other things, eventually
> leading to a simpler volume model where there are only read-write and
> read-only volumes.
> 
> But just respectfully keep on ignoring my opinions.

I do not ignore them, I listen carefully and actually hear what you say.

Consider that neither your opinion nor mine are the "ultimate truth".

Both you and me have good reasons to have our opinions.

Only practice can show which choice makes most people happy (or which
comparison criteria you would consider?).

The best way to prove one's point is to actually show the result of its
application to practice.

This is what I am trying to do. What makes you feel offended?

> Ah, yes the actual useful part in all of this. I have seen very little
> in way of feedback (or patches) coming from your side as far as this is
> concerned. (https://github.com/cmusatyalab/coda-git-conversion/)

Regretfully, I did not plan to contribute to this very important work (cvs
to git migration). If lack of my contribution to this is a showstopper
then I might reconsider but as said it was not what I meant.

Regards,
Rune