View Single Post
Old 05-17-2011, 11:15 AM   #5
hakan42
Zealot
hakan42 is on a distinguished road
 
hakan42's Avatar
 
Posts: 136
Karma: 60
Join Date: Jul 2009
Location: Munich, Germany
Device: Nook Classic rooted; Galaxy S IV with Aldiko, other older devices
Quote:
Originally Posted by user_none View Post
If you do the work, you maintain the work and you can show that the changes are an improvement then it will be considered for inclusion.
Yes, I am willing to do the initial work and the maintenance. Actually, I am locally modifying database2.py and config.py since ages (since August 2009 to be precise) now to keep my estimated 100 lines of changes working.

Quote:
Originally Posted by user_none View Post
I would look over the existing threads about the library structure pull in all reasons for and against then start a non-development section thread to discuss. Go over each for and against and make a clear argument as to why your changes re an improvement. Then take in the responses.and re work your proposal.
Actually, I opened this thread intentionally here in the development area because I am willing to do the work and don't want to get swamped by the usual threads of the form "I want directories to be named 'LN FN' instead of 'FN LN'". This sums up about 80% of the directory naming threads, the rest being "I want to have the genre in the directory name" type of threads. Both get answered by the (very valid) argument of "It's not your directory tree, it belongs to calibre".

The code I am willing to create and maintain would keep all those guys off your back. You could just tell them that if they really really want to modify their storage, they can create / use a plugin, but the main calibre developers only supports the "default" configuration (which would work identically to the current code).

Quote:
Originally Posted by user_none View Post
Again the majority of users and developers are happy with the current implementation. There is little, not 0, chance of getting this accepted.
After some time, the majority accepts the argument that the storage tree of calibre is not theirs to muck around in it (which is a correct argument for most use cases). My use case(s), and the points where they differ from the mainstream calibre operation, I'll enumerate in my answer to kovid's posting.

Regards,
Hakan
hakan42 is offline   Reply With Quote