[Unison-hackers] More invasive code cleanup?

[Benjamin Pierce]

Roughly speaking, there are three sorts of code in Unison: (1)
user-interface, (2) core update detection, propagation, and record-keeping,
and (3) the interface to the filesystem, communication with remote hosts,
and other low-level stuff.

Type (1) code is pretty easy and pretty safe to change and extend. If
there's cleanup to do there, that's also easy.

Type (3) code requires a bit more insight into how Unison works, more OCaml
fluency, and more careful thought about how the information generated at
the low level is used at higher levels. The success of recent work on the
communication protocol, ACLs, etc. shows that it's feasible to continue
making improvements at this level.

Type (2) is a different story. Even when I had my fingers on pretty much
the whole codebase on a regular basis, I was scared to touch the update
detection or reconciliation functionality, and every time I did it was a
stressful (and time consuming) experience. The logic there is very clever
(Jerome Vouillon, who wrote a lot of it, is a *very* good engineer), but
also quite intricate and easy to break. Unless there is a strong need to do
so, I would advocate leaving things alone there.

Best,

    - Benjamin

On Wed, Feb 3, 2021 at 10:01 AM Greg Troxel <gdt at lexort.com> wrote:

>
> 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.
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at LISTS.SEAS.UPENN.EDU
> https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20210203/27c5f567/attachment.htm>