Yesterday, I hacked a little script to use the data in components/INFO
to maintain a local cache of data sheets with a quick viewer.
The idea is as follows: you set an evironment variable DSV_HOME that
points to the root of the cache. In there, the directories ds/ and
bin/ are created for data sheets and executables to display them.
components/INFO as input to download the data sheets and put them into
the cache with more or less sensible names. mkdsv also creates a
script called dsv-<name> in $DSV_HOME/bin that invokes xpdf on the
respective data sheet.
So if you point PATH to $DSV_HOME/bin, you can look at the PMU data
sheet with dsv-pmu or dsv-pcf50633-04-n3 etc. The names are the
names listed in the P: and A: line of INFO.
You can add local aliases with links or by using a shell alias.
scripts/Makefile automates the cache update to a simple "make dsv".
"dsv" just means "Data Sheet View(er)". I picked it over "View Data
Sheet" since Google says the latter is a more common acronym and thus
more likely to clash with something else.
The idea behind this is that it allows everyone to keep the complete
set of data sheets without the need for a central repository. A
central repository would need the permission to redistribute from
all the companies whose data sheet we use, which would be a lot of
overhead, even if they all eventually agree.
In Openmoko, I used a similar command-based access method for a long
time, and found it rather convenient. Saves precious seconds compared
to doing path name completion on the way to the data sheet all the
The cache under $DSV_HOME/ds/ has two levels: there's a directory
named after the P: line for each component, in which the PDF file
resides. The file name is automatically derived from the data sheet
URL, so it can sometimes be very cryptic. Hence the directory.
The script doesn't handle multiple URLs (e.g., because there's more
than one document or because we have different components for the
same symbol) per component yet.