[jgoguen]

Originally Posted by John F

That is disappointing, from previous posts, it looked doable.

It is doable. I did it I just can't justify the additional maintenance work with all the issues it causes. I have a very new infant at home, my priority must be him, which means I have to be quite careful about what I do that takes more of my time. Any changes at all to the database schema in any of the tables affected would require going over the code to make sure it still works and to make changes to support new DB versions. Conveniently enough, the change from DB version 89 (firmware 2.10.0) to DB version 92 (firmware version 3.0.0) makes a schema change to an affected table.

Originally Posted by John F

I would still like to see something done, maybe a separate utility, or an extended extended driver?

You can use the one-off version I attached to an earlier post. Or, the plugin is open source, you can fork the code and maintain you own plugin or you can maintain the relevant code yourself and send me pull requests for updates.

Originally Posted by John F

I'm not sure why default option of disabling it would cause any concerns.

With the ease of enabling it, and the frequency with which documentation and warnings are ignored, it's a matter of time before someone loses data. If it's in the plugin and I maintain it then I need to support it, and I have no interest in supporting this with all of its issues.

Originally Posted by John F

It looks like close to half the people in the poll wanted the feature, which sounds like a pretty good reason to implement it. It seems like a lot more esoteric features have been implemented.

The poll is only part of the whole picture. As I mentioned, I'd spoken to people on both sides and the "no" people tended to have better arguments considering all users. I (and some of them) would also prefer to try to avoid an antagonistic relationship with Kobo and attempt to build a more collaborative relationship. That hasn't worked so well so far from my perspective, but nothing good ever come from being needlessly antagonistic.

Also, some of those more esoteric options were features that I originally refused to implement or felt were better implemented elsewhere. My opinion of having the code in the plugin is not chiselled in stone, but my opinion of not supporting it is pretty darn close.

Originally Posted by John F

For me, the Extended driver is going to be un-necessary.

This may seem odd, being the person who developed and maintains the driver, but I actually hope that Kobo develops to the point where the extended driver is pointless because they use ePub3 features to provide a consistent and equally-awesome experience for all books rather than maintaining their own proprietary modifications and using an inferior (and unsupportable) renderer for non-Kobo books.

Originally Posted by John F

I'm not sure I understand this thinking. If your afraid of it being enabled, have an idiot (or two) message box(s).

I can't put up message boxes without doing something that halts the entire upload process. The best I can do is require someone to go through some sort of needlessly difficult process, which I've done, but if I leave it in the plugin I have to support it and I'm not willing to support it.

Originally Posted by John F

The shelving seems so complex (to the user), yet there is no problem implementing it.

The shelving also carries no risk of data loss.

Originally Posted by John F

Aren't we all doing this with kepub's now? With the database when we edit it for shelve problems?

Again, no risk of data loss. Worst case scenario, you have to factory-reset your reader and re-sync Kobo books and re-send calibre books.

Originally Posted by John F

When we edit the config files?

Which is easily undone if you make a mistake.

Originally Posted by John F

When we side-load fonts?

Again, no risk of data loss.

Originally Posted by John F

When we manually load firmware? When we use plug-ins/patches?

These are probably the only examples that actually compare. The hardest part about manually loading firmware is knowing which link to click (which requires knowing which reader you have...) and unzipping a file. Using plug-ins and patches is your best example, you (probably?) have no idea what these may be doing to the underlying software and they could cause data loss. But in this case, I look at the number of people installing my plugin and ask how many of them (and how many people in general) use a plug-in/patch that actually carries a data loss risk?

Originally Posted by John F

Again, let the user decide, don't be a nanny.

As a full-time software developer for my day job, there's a line between giving the end-user choice and protecting them from themselves. Again, I'm OK with having the code available and in the plugin, but it's going to be harder to enable than a simple check box and I won't support/maintain it.