Library names

[chaley]

I propose that for usb-based devices, calibre creates and maintains a file devinfo.calibre containing the following dict:

devstatus_calibre = {
    'uuid'                : None,
    'calibre_version'     : None,
    'date_last_changed'   : None,
}

Should there be anything else in the dict?

Details:

The device driver (usbms) will read the dict from the file when the device connects (in usbms.device.open), initializing the dict if it does not exist. It will update the file at the end of sync_booklists. A new interface function get_devstatus will be provided to fetch the dict. The interface function will not start a job. An API will be added to the device manager to call it.

The file will be JSON-encoded. Sample code is under the spoiler:

Spoiler:

import json, uuid

from calibre.constants import numeric_version
from calibre.utils.config import to_json
from calibre.utils.date import now

devstatus_calibre = {
    'uuid'                : None,
    'calibre_version'     : None,
    'date_last_changed'   : None,
}

devstatus_calibre['uuid'] = unicode(uuid.uuid4())
devstatus_calibre['calibre_version'] = list(numeric_version)
devstatus_calibre['date_last_changed'] = unicode(now())

print json.dumps(devstatus_calibre, default=to_json)

Design constraints:
1) there can be no data in the dict requiring interaction with the user.
2) the data must be JSON-serializable
3) the dict must be small (less than 512 bytes) and complexity must be low to avoid out-of-space errors or corruption-on-write problems.
4) calibre must be able to survive the file disappearing or being corrupted.

[theducks]

I was just thinking about how to keep the 'snapshot' of the device(s) last list.
Device and CARD ID were the BIG issue.

If it is missing the ID, why not ask for user help in (re-)establishing the ID?

BTW I uniquely name the 'Volumes' for both my device and SDCARD (removable cards can move around and should not be locked into a single device if found in a multi-device library)

Identity by
1) calibre ID
2) device ID (eg ser#)
3) volume ID
4) book list match (possible ID)

[chaley]

Originally Posted by kovidgoyal

That's a possibility, the problem is it is not very reliable. You can in principle "remove" a plugin by just deleting its zip file in the calibre config directory. In such a case calibre has no way to run plugin specific cleanup code.

If the suggested preference name scheme is followed, then the calibre GUI can, after startup, delete the db preferences for any plugin that isn't loaded. For this check, disabled would need to equivalent to loaded.

If we really want to get fancy, the cleanup code can be included in the preferences and run just before the preferences are deleted.

[chaley]

Originally Posted by theducks

If it is missing the ID, why not ask for user help in (re-)establishing the ID?

The device driver plugins cannot use/depend on GUI interaction, so the file's default contents must be determinable without user input. If someone wants to write GUI code to alter the file's contents, a basic write API can be provided.

Identity by
1) calibre ID
2) device ID (eg ser#)
3) volume ID
4) book list match (possible ID)

My guess is that you want a library ID, not the calibre installation ID.

What is a volume ID, and where did it come from?

What is "book list match" and where did it come from? My guess is that it the information is already in metadata.calibre

The device ID will be a UUID assigned by calibre. Many devices don't have a built-in ID, and I have no interest in figuring out how to get the ID for devices that do but that I don't own. If such a thing is necessary, someone else can take on this challenge.

There would be such a file on each memory location.

[kovidgoyal]

Originally Posted by chaley

If the suggested preference name scheme is followed, then the calibre GUI can, after startup, delete the db preferences for any plugin that isn't loaded. For this check, disabled would need to equivalent to loaded.

If we really want to get fancy, the cleanup code can be included in the preferences and run just before the preferences are deleted.

Since I'm adding a library UUID, I think we'll leave it as is since there isn't really a use case for this at the moment.

[kovidgoyal]

@chaley: I'd suggest just extending the current get_info method to return this info as well and sticking it onto the device object so it only has to be read once.

[chaley]

Originally Posted by kovidgoyal

@chaley: I'd suggest just extending the current get_info method to return this info as well and sticking it onto the device object so it only has to be read once.

I was going to read it only once.

I thought of changing the get_info method, but then I hesitated to change a published API. That is probably silly, though, because there is almost certainly only one user -- gui.devices.

[kovidgoyal]

Yeah only gui2.device and prs500.cli as per grep

[theducks]

Originally Posted by chaley

The device driver plugins cannot use/depend on GUI interaction, so the file's default contents must be determinable without user input. If someone wants to write GUI code to alter the file's contents, a basic write API can be provided. My guess is that you want a library ID, not the calibre installation ID.

What is a volume ID, and where did it come from?

It is the optional use part of the Windows/linux File system.
I name all my SD/pen drives/HD partitions. eg.

C:\Documents and Settings\shop1>vol
 Volume in drive C is C-clamp
 Volume Serial Number is F857-3467

P:\>vol
 Volume in drive P is BOOKS1
 Volume Serial Number is 8483-EA81

P: is my device SD card

I think all FAT volumes have a serial ID

What is "book list match" and where did it come from? My guess is that it the information is already in metadata.calibre

Correct.
I was suggesting one way to ID the (device) storage (with a damaged ID file) was a fast compare with the snapshots in the archived 'on device libraries'. Not perfect. If it reached a threshold of 'hits', the user could be queried: 'Is this Charlies PRS-300?'

The device ID will be a UUID assigned by calibre. Many devices don't have a built-in ID, and I have no interest in figuring out how to get the ID for devices that do but that I don't own. If such a thing is necessary, someone else can take on this challenge.

There would be such a file on each memory location.

[chaley]

Originally Posted by theducks

It is the optional use part of the Windows/linux File system.
I name all my SD/pen drives/HD partitions. eg.

C:\Documents and Settings\shop1>vol
 Volume in drive C is C-clamp
 Volume Serial Number is F857-3467

P:\>vol
 Volume in drive P is BOOKS1
 Volume Serial Number is 8483-EA81

P: is my device SD card

I think all FAT volumes have a serial ID

I can't find a cross-platform way to get this information. The device UUID will stand-in for it.

Correct.
I was suggesting one way to ID the (device) storage (with a damaged ID file) was a fast compare with the snapshots in the archived 'on device libraries'. Not perfect. If it reached a threshold of 'hits', the user could be queried: 'Is this Charlies PRS-300?'

What is the "archived on device libraries"? It can't be the list in the ID file you proposed, because if the file is damaged then the list isn't there. There isn't any such thing in the library.

[chaley]

Taking into account theduck's suggestions, I now have device_info containing:

{'info': [
      'Folder Device', '', '', '', 
      {'main': 
        {'device_store_uuid': '586a8563-679d-45cf-8c82-fd6100143fd8', 
         'calibre_version': u'0.7.47', 
         'prefix': u'C:/Users/charles/Desktop/debug/', 
         'last_library_uuid': 'THIS IS A UUID', 
         'date_last_connected': u'2011-02-28 13:13:00.776000+00:00'
        }
      }
    ], 
  'prefixes': (None, None), 
  'freespace': (321195761664L, 0, 0)}

The record is a dict of three elements: 'info', 'prefixes', and 'freespace'.

The first 4 elements of the 'info' list are the device type name, device version, software version on device, and mime type. In most cases the 2nd through 4th are not known and are set to ''. The fifth element in the list is the driveinfo dict containing up to three keys: 'main', 'A', and 'B', providing information about the memory in the device. The key and associated data will be there only if the device has the memory location installed. If the device does not support driveinfo, then the dict will be contain no keys.

device_store_uuid will be set the first time that calibre sees a device or a card. last_library_uuid will be UUID of the library open in calibre when the device was last connected (once we have it)

The 'prefixes' list contains two elements: the path to memory cards A and B if the memory is installed, otherwise None.

The 'drivespace' list contains three elements: the amount of free space on main memory, card A, and card B.

The API for fetching the information is device_manager.get_current_device_information().

[kiwidude]

At the risk of drifting us even further off ... if a device uuid is now being persisted on the device, does anyone have any interest in enhancing the autodownload news stuff to allow it to be associated with a uuid? So that you could have device specific news lists? Which is what my book sync plugin would need as mentioned by meme above? Or shall I just raise a ticket for it as a potential future addition?

Also, is there going to be any kind of database entry in Calibre for the device where some kind of name could be associated with it as meme raised? Otherwise we will all in our plugins be replicating code requiring the user to "identify" a name for the uuid?

[chaley]

Originally Posted by kiwidude

does anyone have any interest in enhancing the autodownload news stuff to allow it to be associated with a uuid?

I have no interest in doing that.

Also, is there going to be any kind of database entry in Calibre for the device where some kind of name could be associated with it as meme raised? Otherwise we will all in our plugins be replicating code requiring the user to "identify" a name for the uuid?

I don't know. Getting and maintaining the UUID ==> human_name map information will require a bunch of GUI and preferences work that I am not prepared to do, but someone else might be.

[kiwidude]

Originally Posted by chaley

I have no interest in doing that.
I don't know. Getting and maintaining the UUID ==> human_name map information will require a bunch of GUI and preferences work that I am not prepared to do, but someone else might be.

Fair enough . I was just re-raising the issue in case that file above was the right place for it but perhaps the most "useful" place would be I guess some cross-library Calibre file which I guess "prefs" is.

[theducks]

Originally Posted by chaley

What is the "archived on device libraries"?

What I am calling the 'archived on-device library' is saving the info (listing) you see in one of the device views for the current connected device.

eg. my PEz: Main and Card_A = 2 snapshots into/updating the archive once ID's are established.
My idea was to provide a way to 'view' a snapshot (currently disappears, when disconnected) of what was on a device(s).

Another goal, would to lay the ground work for a re-occurring, multi-user library permissions management suggestions