Sigil's method was also part of the overhead in performance. All links had to be verified upon opening. Whatever algorithm was used for IDs had to remain resident in memory and tracked for each page to ensure uniqueness. It needed to know what came before so it could generate what should come next. It's unnecessarily complex for the
ridiculously simply purpose these fragments/ids serve, in my opinion.
The UUID method, while maybe slightly aesthetically unpleasing, has the benefit of just plain
working--with almost zero overhead--for every single book, every single time. No matter the length/complexity, or how many times a file might be split/merged/re-split/remerged without fail ... and dead-nuts
simple. Generate a UUID (
any UUID) and BAM! you're done. Unique. Forever (unless someone
manually copies and pastes). I'd choose that method if I was writing the code to automate this sort of thing for all users/all books/all the time/every time. It'd be foolish not to.
I do understand not liking "how it looks", though. But then again, I usually work with books where every link can always point to the top of a new file anyway. No frag/id required.
