[Unison-hackers] More invasive code cleanup?

[Greg Troxel]

Tõivo Leedjärv <toivol at gmail.com> writes:

> Eventually version compatibility will be broken (for example, when
> switching to a more stable protocol). When version compatibility is
> going to be broken, what is the appetite for other more invasive
> changes? I would like to get opinions and arguments.

I think the protocol breaks (both ocmal and otherwise) are the biggest
problems unison has right now, by a wide margin.  Obviously (backwards
compat being hard probably) we're going to have another break as we move
to some stable format that is with any luck extendable.

In my view, it would take a very good reason to have protocol break
before the big break.  To put that in perspective, I don't think ACL
support is a good enough reason, based on the balance of bugtracker and
list comments about protocol breaks vs "I can't use unison because I
need ACL sync".

I know Stéphane has some code for a new protocol, and I think we should
have a big picture discussion about the approach.  The world has
increasing gone to "JSON is the answer" for interchange in many places,
and there is BSON.  I realize there is also protobuf and some others.  I
would like to avoid a format used only by uniso, and prefer a way to use
something maintained by others and widely depended on.   Besides that
sort of issue, I think we need a plan for being able to extend the
format while allowing version compat.   The ACL changes -- but I could
be confused -- seem like a good trial case.  Basically, design a format
for unison w/o ACL, and then a change or ACL, and evaluate if the two
versions will interop when not doing acl sync.

> I am thinking of several code cleanup and maintenance changes, not all
> of which break version compatibility, that can be more invasive and
> need more preparation, review and testing.
>
> Just as an example, from the top of my head:
>  - Removing CTimeStamp (which has long not been used) -> changes archive format

So that would be another thought experiment for the new format.

>  - system/system_win* seems to be nearly (or completely) obsolete with
> newer OCaml versions and might be removed. Once that is gone, all
> system/* becomes obsolete?
>  - In several places in code you find FIXME and TODO markers
>  - Sometimes you find comments like (*FIX: remove when Unison version > 2.40 *)

I don't object to these.   But I would like to see others review and
test.  I wonder if we should be thinking about improved automated tests
before this sort of rototill.

>  - There is some code for functions that are now covered by Stdlib (I
> assume the code is in Unison tree because it was not available in
> earlier versions of OCaml)

I don't understand enough to have an opinion (but sounds reasonable).

> Is there readyness to review and test? Or is the wider opinion to
> leave the code alone as much as possible and only maintain it to keep
> it running with newer OCaml and OS versions?

I would love to hear from others who are willing to spend time on this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20210203/577cea95/attachment-0001.asc>