[Winmerge-development] Compare lib - planning

[Kimmo V. <ki...@wi...>]

So we've certainly discussed about this approach. And it seems there is 
no vocal opposition so I think it is time to get finally started with 
this compare lib thingie.

Just to repeat this idea:
- we create a new layer and API for compare functionality. In practice, 
replace current CDiffWrapper with something sane.
- main point is we very very clearly separate our compare lib code 
(behind the stable API) from GUI code. And I mean clearly. There won't 
be random pointers or windows messages used past that API as there is 
currently.
- compare lib being in one module with stable API we can really update 
both compare code and GUI independently. And this also allows to 
implement different GUIs later using that compare lib API. I don't say 
there will be other GUIs, but I say we make it possible.
- when we create a API, we can unit-test it! This is one of the biggest 
reasons I want this. Anyone who has used unit-testing with code modules 
knows how wonderful tool it can be. Currently we have very little 
possibilities to reliably test our compare code. I'd say our goal must 
be to add at least some unit tests to build procedure, so that whenever 
some breakage happens, it gets noted immediately. Not after months being 
in stable release.
- we can also start creating compare lib a cross-platform.
- in which using APR helps enormously.
- again, cross-platform is not a primary goal, it is something we gain 
by using lots of heavily tested code in APR. Instead of writing our own 
code for that functionality.


What I tried to start discussing earlier in forums, but which morphed 
into something else was:
- tasks
- features
- limitations

Tasks are:
- compare two folders, give back list of statuses for individual 
files/folders
- compare two files, give back list of differences inside files

There are a lot of details, but I think it is wise to first agree about 
top-level things.

Features:
- filtering
- unicode support (APR gives us UTF-8 so I think it is a good choice)
- codepage support (APR helps us a lot)
- patch creating and applying (do these belong here?)
- different compare methods (currently diffutils, quick compare, date 
and or time)
- 64-bit support for filesizes etc
- code 64-bit clean meaning we can build it later for 64-bit Windows
- hooks for plugins? No COM!

Limitations:
- 3-way compare not implemented, but we should not prevent it in desing
- only local files and folders (or network shares), not FTP, HTTP etc

Ok, I think this is enough for a first post. :)

Regards,
Kimmo

-- 
Kimmo Varis
ki...@wi...