Time to make some choices about vCardSplit

vCardSplit has now been in the wild unchanged for almost seven years.

During all that time, it has collected three bug reports.

  1. It doesn't handle Mac/UNIX file formats
  2. It doesn't handle unicode
  3. It requires a geeky user

It's time to tackle that list.

But that means making decisions. So I've decided to write up those decisions, in order to help me work them out and to keep development of the program somewhat transparent.

 

It doesn't handle Mac/UNIX file formats
This first bug is easy- no decisions required.
UNIX systems and Apple's Mac computers use a different way to tell when a line ends than the one Windows uses.
I can work around that - at the moment I detect where this difference may occur, and print a warning. I just need to replace that warning with an attempt to re-encode to a temporary file, and then use that temporary file.
It's not elegant, but it is transparent to the user and it fixes the bug, so it's decided.

It doesn't handle unicode
The second bug - it doesn't handle unicode - is harder.
Files can be encoded in two types - old-style ANSI or new-style unicode. ANSI only allows the normal British/American character sets to be used in any reliable form. Unicode allows international characters, such as those with accents.
I have a later version of the compiler, which will handle unicode for me. But if I use that feature, then I may have to drop unicode support on older operating systems - basically, on Windows 9x and Windows ME.
Those older systems don't have full unicode support, but the compiler has a library it can use to work around that. And if the words "library" and "work around" appearing in the same sentence don't make you worry, then it's OK - you've just never written any reliable software.
For example, even if I can read the files, can I use that data? I build output filenames based on the content, and I doubt Windows 95 will allow me to use a unicode filename - whereas Windows 2000 and higher will do.

And then there's more to decide. If I'm handling both old-style ANSI and new style unicode files, what's my default? How do I force a file to be read as one or the other? What should the output file type be?
vCardSplit has always taken just one argument - the file to split - on its command line. This meant I didn't have to write any parsing code, and kept things simple. Supporting unicode doesn't just mean code to handle file types, but also code to parse the command line arguments that become possible due to those types. If I were to have to pull an estimate out of my posterior about how much more code it will require, I'd say it might even double the size of the program.
Given how small it is, this is not the end of the world - but it's more work than you might think, and a lot more than has already gone into vCardSplit.

When I started writing this out, I was in favour of trying to support unicode on all platforms. Now I don't think this is possible, so I've made three important decisions:

  • The next version of vCardSplit will support unicode. (It isn't right to automatically exclude so many users.)
  • The next version will assume unicode input, but this can be overridden.
  • The next version will assume unicode output, unless the input format is overridden.

An interesting by-product of these decisions is that I can now add other command line options - such as overriding the output directory.

It requires a geeky user
This is the last bug, and an easy one to decide on.

I won't fix it.

My reasoning is thus: The non-geeky user who simply downloads the app and tries to run it gets, at worst, a flash of a console window (as the app says "you have to give me a filename") and then nothing. If they read the instructions and don't understand them, I've been known to try to help, but it's very difficult. In fact, it's insanely difficult. How do you feel about trying to guide people who know nothing about the command line through command line operations via an email conversation? In your own time, without being paid for it? Exactly.

In its current form, nothing I can do will fix this. The only way to fix this is to build a proper GUI version.

However, a GUI version isn't scriptable. So there will still need to be a console version - and the core code for a GUI version would be taken from the current console version anyway. So this leaves me with an obvious path - fix the console version first, then revisit fixing this bug.

But for the moment, I don't see how it's practical to fix this particular bug.

A friend asked me why not delay by 20s when no argument is present, so that the window doesn't vanish? Well, the assumption is that the program is called from the Windows Command Prompt - that's the usage case it's written for. So I could check to see if the parent process is cmd.exe and pause for twenty seconds. But what if you're calling it from an alternate shell like 4NT, Take Command, or bash (from cygwin or other toolsets)? What if the lack of a filename is due to a script error - is a 20s delay going to win me friends? For dyslexic users, is a 20s delay long enough to read it anyway?
So the assumption that the parent command process will be called cmd.exe is not one I want to make, as it might penalise some users - and worse, it might break mightily if Microsoft makes a (very unlikely) change in the future, and the delay is unwelcome for some use cases and may not be good enough for some users.
I think it's better to spend time developing a GUI than it is to put a kludge like this in. So my decision remains unchanged...

Conclusion
So, there we have it.

Soon, there should be a new version of vCardSplit that supports Mac/UNIX vCard files, and supports unicode. But the price is that it won't work on Windows 9x and Windows ME, and it won't be any easier to use. It might even be harder to use.

But if it's also being used six years and ten months after its release, I'll know I made the right decisions...