having determined with griker's help why calibre did what it did i have several questions.

how does calibre 'know' which periodicals have all ready been uploaded to the devices?

assuming that calibre stores this information somewhere, where does calibre store this information?

i assume that calibre assumes that there is only one device that it is uploading to automatically. is it correct to assume that calibre does not make any differentiation between devices, there is no way to have calibre upload periodicals to the 32GB iPod but not the 64GB iPod nor the 16GB iPod.

i have not programmed in python before so it is taking me time to read and understand the source code. slowly but surely i am beginning to understand the 'class DynamicConfig'
. concerning ~/Library/Preferences/calibre/dynamic.pickle (this is on macosx) is there any documentation concerning the structure of the file. using 'hexdump -C dynamic.pickle' i am able to determine some of the structure. to be honest it is strictly hit-n-miss.

i have been attempting to use the pickle module and have come to the conclusion that while i am calling it correctly the dynamic.pickle file itself is causing python to search for the module calibre.utils.config . from what i am able to figure out, in the very beginning of the dynamic.pickle file is the name of the module and defined class that was used to create the pickle file. in this case that is calibre.utils.config.DynamicConfig .
to be able to use python to unpickle the pickle file i need to create a 'package' of the necessary python code from calibre and install it in the python sys.path so that python is able to find the module 'calibre.util.config' which will be used to unpickle the dynamic.pickle file. python appears to have the idea that the module and class that wrote the pickle file should be used to unpickle the pickle file.

the alternative of using python would be to use perl or straight c programming to unpickle the dynamic.pickle file. the disadvantage of doing so is not knowing what the structure of the dynamic.pickle file is. i am then back to hit-n-miss.

the upside is that after years of avoiding it i am learning python.
i am learning why not to use 'canned' routines to save configuration information.

i am learning why not to use 'canned' routines to save configuration information.

the pickle file is just a serialization of a Python object which is why the original class file is needed to make sense of it. The advantage from a developers point of view is that no special code is needed to read/write the configuration information as one simply re-instantiates the original python object.

Exactly the same issue would apply in any language that allow objects to be serialized and then reloaded.