MobileRead Forums - View Single Post - Need advice for creating a slightly odd type of plugin

ldolse · 05-19-2011, 10:40 AM

I've got some friends doing archaeoastronomy on a research grant. They currently get datapoints in an extremely painstaking way from a NASA web application. When they described what they were doing I thought I could help them out with a script. While Calibre might not seem like the right place to create something like this, it made sense for a couple reasons:

Kovid's done a lot of heavy lifting around a very functional mechanize browser and other bundled functions
My friends aren't so techy I'd want to make them do CLI stuff all the time that a simple standalone script would require, and Calibre provides the heavy lifting here too with it's plugin UI.
Most importantly, Calibre can automatically convert the results to a variety of formats compatible with ipad, iphone, etc, a concept which my friends are big fans of

My questions are really how to go about making this work from a fine tuning perspective. I've already created a script I can execute from the CLI using calibre-debug that does all the heavy lifting. The user needs to configure a date in the past using UTC time for the celestial body they want to track, and then ideally an offset for the setting time. They also need to set the longitude/latitude coordinates. I plan to allow multiple events to be queried in one go.

I'm running into a couple issues and places where some advice would help.

Issue - When I tried using Calibre's parse_date function it converted UTC time to local time. NASA requires UTC. How do I keep Calibre using UTC for all date functions? Right now I'm just configuring start/end times by hand, but I want to start calculating offsets, which will require proper date handling.

Bonus points for this question - the dates my friends are using may go back far enough that they need to specify AD vs. BC - is that something Python's date functions would be up for handling? For now I'm just going to tell them to stick with dates past a certain year as they don't require special handling, but I may want to add support for this later. The NASA system also requires a specific format for BC dates, so that may be another hurdle.

Lastly I need advice on how to handle the actual plugin. My thinking is a file-type plugin. At first I thought I might have the user input the date/coordinates directly into a text file with a special extension, but now I'm thinking that would be more reliably handled in the plugin configuration dialog. That means to trigger the plugin one would just add a blank text file with a specific extension to Calibre and the rest would be done based on the config - does this make sense?

Once the input plugin is triggered I think I'll want to convert the results to a traditional format - probably zipped html - I believe an input format plugin can actually store a different format in Calibre's db/filesystem - I'm pretty sure the Topaz input plugin does this today.

Any thoughts on alternative approaches would be appreciated. Note I'm mostly out in the field with my friends at the moment, so any failures to respond reflect my lack of Internet access vs. lack of appreciation.

05-19-2011, 10:40 AM	#1
ldolse Wizard Posts: 1,337 Karma: 123455 Join Date: Apr 2009 Location: Malaysia Device: PRS-650, iPhone	Need advice for creating a slightly odd type of plugin I've got some friends doing archaeoastronomy on a research grant. They currently get datapoints in an extremely painstaking way from a NASA web application. When they described what they were doing I thought I could help them out with a script. While Calibre might not seem like the right place to create something like this, it made sense for a couple reasons: Kovid's done a lot of heavy lifting around a very functional mechanize browser and other bundled functions My friends aren't so techy I'd want to make them do CLI stuff all the time that a simple standalone script would require, and Calibre provides the heavy lifting here too with it's plugin UI. Most importantly, Calibre can automatically convert the results to a variety of formats compatible with ipad, iphone, etc, a concept which my friends are big fans of My questions are really how to go about making this work from a fine tuning perspective. I've already created a script I can execute from the CLI using calibre-debug that does all the heavy lifting. The user needs to configure a date in the past using UTC time for the celestial body they want to track, and then ideally an offset for the setting time. They also need to set the longitude/latitude coordinates. I plan to allow multiple events to be queried in one go. I'm running into a couple issues and places where some advice would help. Issue - When I tried using Calibre's parse_date function it converted UTC time to local time. NASA requires UTC. How do I keep Calibre using UTC for all date functions? Right now I'm just configuring start/end times by hand, but I want to start calculating offsets, which will require proper date handling. Bonus points for this question - the dates my friends are using may go back far enough that they need to specify AD vs. BC - is that something Python's date functions would be up for handling? For now I'm just going to tell them to stick with dates past a certain year as they don't require special handling, but I may want to add support for this later. The NASA system also requires a specific format for BC dates, so that may be another hurdle. Lastly I need advice on how to handle the actual plugin. My thinking is a file-type plugin. At first I thought I might have the user input the date/coordinates directly into a text file with a special extension, but now I'm thinking that would be more reliably handled in the plugin configuration dialog. That means to trigger the plugin one would just add a blank text file with a specific extension to Calibre and the rest would be done based on the config - does this make sense? Once the input plugin is triggered I think I'll want to convert the results to a traditional format - probably zipped html - I believe an input format plugin can actually store a different format in Calibre's db/filesystem - I'm pretty sure the Topaz input plugin does this today. Any thoughts on alternative approaches would be appreciated. Note I'm mostly out in the field with my friends at the moment, so any failures to respond reflect my lack of Internet access vs. lack of appreciation. Last edited by ldolse; 05-19-2011 at 11:09 AM.