Re: [documancer] Using Documancer for HTML books on CD

[Kevin O. <ke...@tu...>]

Hi,

On Apr 1, 2004, at 12:28 AM, Vaclav Slavik wrote:

[snip]

>
>> Furthermore, what would be nice is if
>> Documancer could remember CD-based books in the book manager, and
>> when such a book was selected, it would prompt something like
>> "Please insert the CD-ROM for book X to load this book."
>>
>> Here is what I suggest as a solution to these issues:
>>
>> 1) Have Documancer's wxConfig write a Version key upon startup.
>> This way I can check to see if Documancer is of a high enough
>> version to support what we're doing.
>
> I don't want to do this -- what if you use two versions? They'd keep
> fighting over the value. And if the user didn't run Documancer yet,
> there would be no ~/.documancer/config.ini and thus no version info.
>
> OTOH, being able to run "documancer --version" would be useful (done
> in CVS). And maybe a registry entry on Windows with path to installed
> Documancer, as (HKLM or HKCU)\Software\V.S.
> \Documancer\${version}\path. Would that suffice? You can look into
> HKLM\Software\V.S.\Documancer (and if it doesn't exist, HKLM) to see
> all (typically, 1) version numbers under it.

Sure, this is what I'm looking for. =)

>> 2) Either create a "mybook.book" persistent storage format for book
>> configs, or pass in the book's "index.htm(l)" to have it added into
>> Documancer's book manager. (I assume from there Documancer would
>> see if an index exists, etc.)
>
> I wanted to avoid having Documancer-specific file format. Instead, I
> want to be able to handle _any_ relevant format out there. If you
> look at what book definition contains, majority of it is user's
> customization, i.e. something you don't want to be part of .book
> format -- things like font settings (to be done), whether you want
> fulltext index or not and so on.

I see ".book" as more of a metadata file than as the actual content 
file. Take an EClass, for example. I've already produced a full-text 
index, so there isn't any reason someone wouldn't want full-text search 
to be enabled. (Well, no logical reason, at least. :-) So in this case 
my .book would contain the settings to turn that on, and tell 
Documancer anything else it needs to know about the format of the 
content, etc. Settings like font, etc. could be left blank, and when 
the user opens the ".book" file, it could ask them if they want the 
"book" added to their "Bookshelf" (the book manager), and from there 
they will have a locally writable copy of the settings they can change 
and save. Otherwise, they can change things on a session-by-session 
basis, but they can't make permanent changes. Or, we may actually be 
talking about two different files here - book metadata would be a nice 
thing to have and expand (i.e. author, date published, web site, 
contact email, etc.). These aren't really short term needs, but they 
fit under that "used in ways other than you expected" category. :-)

> OTOH, I'm thinking about moving book definition from config file into
> separate files (one per book) for easier (manual) maintainance and to
> allow merging of books from different sources (like globally
> available books and your private ones, books installed by default
> etc.). That could be (ab)used for your purposes as well: you would
> add a new path to book files (using something like "documancer
> --add-books-path /foo/bar") and put all your books there.

Sure, actually, people who develop EClasses have all of their content 
stored in ~/EClass Projects, so I could add this folder so it will look 
for books there.

>> The former approach is IMHO advantageous as on Mac I could tell
>> people to double-click the ".book" file to load it into Documancer.
>
> That's what I'd like to have in 1.0 for any format -- let Documancer
> recognize the format, create book definition (if possible, otherwise
> with user's help) and file it into "Temporary Books" folder. That's
> because I recently had to work with manuals about things I'll never
> need again in foreseeable future (like learning how to embed PDF and
> PNG figures in LaTeX documents) and the books approach is not best
> for that. Instead, I want to open a file (without having to define
> the book), use it for a while and then forget about it -- and don't
> waste space for index or in books list.
>
>> It also means that you could have a simple "Open File" approach to
>> loading books - just pick the .book file and click OK to load it.
>> (If you pick another type of file, like html, or man, it will
>> prompt you for the necessary info.)
>
> Yes, exactly the idea.
>
>> 3) Maybe some sort of BOOK_ON_CD setting.
>
> I think it's not needed: if the data providers were able to return
> list of files they use (and I will need this to be able to
> automatically update indexes), Documancer could check for their
> presence (again, it will do this because of another feature anyway)
> and if all them were missing *and* they were located on removable
> medium, it would tell the user to insert it.

I know this is easy enough to do on Unix, but on Windows with their 
drive system, any drive could be removable storage, or could be a 
permanent storage drive. (i.e. "D:" is usually a CD-ROM, but if the 
user partitions the drive, that assumption is broken.) There might be a 
way to query the drive to see if its removable storage, but I'm not 
sure how to go about that... If you don't have an answer for this I can 
look into it.

Thanks,

Kevin