[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] r23703 - Extractor/doc Extractor-docs/WWW
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] r23703 - Extractor/doc Extractor-docs/WWW |
|
Date: |
Sat, 8 Sep 2012 10:32:35 +0200 |
Author: grothoff
Date: 2012-09-08 10:32:35 +0200 (Sat, 08 Sep 2012)
New Revision: 23703
Added:
Extractor/doc/libextractor.texi
Removed:
Extractor/doc/extractor.texi
Modified:
Extractor-docs/WWW/run-gendocs.sh
Extractor/doc/Makefile.am
Log:
renaming
Modified: Extractor/doc/Makefile.am
===================================================================
--- Extractor/doc/Makefile.am 2012-09-08 08:30:59 UTC (rev 23702)
+++ Extractor/doc/Makefile.am 2012-09-08 08:32:35 UTC (rev 23703)
@@ -1,7 +1,7 @@
man_MANS = extract.1 libextractor.3
EXTRA_DIST = $(man_MANS)
-DISTCLEANFILES = extractor.cps
-info_TEXINFOS = extractor.texi
+DISTCLEANFILES = libextractor.cps
+info_TEXINFOS = libextractor.texi
extractor_TEXINFOS = gpl.texi
Deleted: Extractor/doc/extractor.texi
===================================================================
--- Extractor/doc/extractor.texi 2012-09-08 08:30:59 UTC (rev 23702)
+++ Extractor/doc/extractor.texi 2012-09-08 08:32:35 UTC (rev 23703)
@@ -1,1019 +0,0 @@
-\input texinfo @c -*- Texinfo -*-
address@hidden % The structure of this document is based on the
address@hidden % Texinfo manual from libgcrypt by Werner Koch and
address@hidden % and Moritz Schulte.
address@hidden %**start of header
address@hidden extractor.info
address@hidden version.texi
address@hidden The GNU libextractor Reference Manual
address@hidden Unify some of the indices.
address@hidden %**end of header
address@hidden
-This manual is for GNU libextractor
-(version @value{VERSION}, @value{UPDATED}), a library for metadata
-extraction.
-
-Copyright @copyright{} 2007, 2010, 2012 Christian Grothoff
-
address@hidden
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3
-or any later version published by the Free Software Foundation;
-with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
-Texts. A copy of the license is included in the section entitled ``GNU
-Free Documentation License''.
address@hidden quotation
address@hidden copying
-
address@hidden Software libraries
address@hidden
-* Libextractor: (extractor). Metadata extraction library.
address@hidden direntry
-
-
-
address@hidden
address@hidden Titlepage
address@hidden
address@hidden
address@hidden The GNU libextractor Reference Manual
address@hidden Version @value{VERSION}
address@hidden @value{UPDATED}
address@hidden Christian Grothoff (@email{christian@@grothoff.org})
-
address@hidden
address@hidden 0pt plus 1filll
address@hidden
address@hidden titlepage
-
-
address@hidden
address@hidden
-
-
address@hidden gnu{}
address@hidden
address@hidden macro
-
address@hidden gpl{}
address@hidden
address@hidden macro
-
address@hidden api{}
address@hidden
address@hidden macro
-
address@hidden cfunction{arg}
address@hidden()}
address@hidden macro
-
address@hidden mynull{}
address@hidden
address@hidden macro
-
address@hidden gnule{}
address@hidden libextractor}
address@hidden macro
-
-
address@hidden
address@hidden Top
address@hidden The GNU libextractor Reference Manual
address@hidden
address@hidden ifnottex
-
address@hidden
-* Introduction:: What is @gnule{}.
-* Preparation:: What you should do before using the library.
-* Generalities:: General library functions and data types.
-* Extracting meta data:: How to use @gnule{} to obtain meta data.
-* Language bindings:: How to use @gnule{} from languages other than
C.
-* Utility functions:: Utility functions of @gnule{}.
-* Existing Plugins:: What plugins are available.
-* Writing new Plugins:: How to write new plugins for @gnule{}.
-* Internal utility functions:: Utility functions of @gnule{} for writing
plugins.
-* Reporting bugs:: How to report bugs or request new features.
-
-Appendices
-
-* GNU Free Documentation License:: Copying this manual.
-
-Indices
-
-* Concept Index:: Index of concepts and programs.
-* Function and Data Index:: Index of functions, variables and data types.
-* Type Index:: Index of data types.
-
address@hidden menu
-
-
-
address@hidden **********************************************************
address@hidden ******************* Introduction ***********************
address@hidden **********************************************************
address@hidden Introduction
address@hidden Introduction
-
address@hidden error handling
address@hidden is GNU's library for extracting meta data from
-files. Meta data includes format information (such as mime type,
-image dimensions, color depth, recording frequency), content
-descriptions (such as document title or document description) and
-copyright information (such as license, author and contributors).
-Meta data extraction is an inherently uncertain business --- a parse
-error can be a corrupt file, an incompatibility in the file format
-version, an entirely different file format or a bug in the parser. As
-a result of this uncertainty, @gnule{} deliberately
-avoids to ever report any errors. Unexpected file contents simply
-result in less or possibly no meta data being extracted.
-
address@hidden plugin
address@hidden uses plugins to handle various file formats.
-Technically a plugin can support multiple file formats; however, most
-plugins only support one particular format. By default,
address@hidden will use all plugins that are available and found
-in the plugin installation directory. Applications can
-request the use of only specific plugins or the exclusion of
-certain plugins.
-
address@hidden is distributed with the @command{extract}
address@hidden distributions ship @command{extract} in a
-seperate package.} which is a command-line tool for extracting
-meta data. @command{extract} is given a list of filenames and
-prints the resulting meta data to the console. The @command{extract}
-source code also serves as an advanced example for how to use
address@hidden
-
-This manual focuses on providing documentation for writing software
-with @gnule{}. The only relevant parts for end-users
-are the chapter on compiling and installing @gnule{}
-(@xref{Preparation}.). Also, the chapter on existing plugins maybe of
-interest (@xref{Existing Plugins}.). Additional documentation for
-end-users can be find in the man page on @command{extract} (using
address@hidden|man extract|}).
-
address@hidden license
address@hidden is licensed under the GNU General Public License,
-specifically, since version 0.7, @gnule{} is licensed under GPLv3
address@hidden any later version}.
-
address@hidden Preparation
address@hidden Preparation
-
-This chapter first describes the general build instructions that
-should apply to all systems. Specific instructions for known problems
-for particular platforms are then described in individual sections
-afterwards.
-
-Compiling @gnule{} follows the standard GNU autotools build process
-using @command{configure} and @command{make}. For details on the GNU
-autotools build process, read the @file{INSTALL} file and query
address@hidden|./configure --help|} for additional options.
-
address@hidden has various dependencies, most of which are optional.
-Instead of specifying the names of the software packages, we
-will give the list in terms of the names of the respective
-Debian (unstable) packages that should be installed.
-
-You absolutely need:
-
address@hidden @bullet
address@hidden
-libtool
address@hidden
-gcc
address@hidden
-make
address@hidden
-g++
address@hidden
-libltdl7-dev
address@hidden itemize
-
-Recommended dependencies are:
address@hidden @bullet
address@hidden
-zlib1g-dev
address@hidden
-libbz2-dev
address@hidden
-libgif-dev
address@hidden
-libvorbis-dev
address@hidden
-libflac-dev
address@hidden
-libmpeg2-4-dev
address@hidden
-librpm-dev
address@hidden
-libgtk2.0-dev
address@hidden
-libgsf-1-dev
address@hidden
-libqt4-dev
address@hidden
-libpoppler-dev
address@hidden
-libexiv2-dev
address@hidden
-libavformat-dev
address@hidden
-libswscale-dev
address@hidden itemize
-
-For Subversion access and compilation one also needs:
address@hidden @bullet
address@hidden
-subversion
address@hidden
-autoconf
address@hidden
-automake
address@hidden itemize
-
-Please notify us if we missed some dependencies (note that the list is
-supposed to only list direct dependencies, not transitive
-dependencies).
-
-Once you have compiled and installed @gnule{}, you should have a file
address@hidden installed in your @file{include/} directory. This
-file should be the starting point for your C and C++ development with
address@hidden The build process also installs the @file{extract} binary and
-man pages for @file{extract} and @gnule{}. The @file{extract} man page
-documents the @file{extract} tool. The @gnule{} man page gives a brief
-summary of the C API for @gnule{}.
-
address@hidden packageing
address@hidden directory structure
address@hidden plugin
address@hidden environment variables
address@hidden LIBEXTRACTOR_PREFIX
-When you install @gnule{}, various plugins will be
-installed in the @file{lib/libextractor/} directory. The main library
-will be installed as @file{lib/libextractor.so}. Note that
address@hidden will attempt to find the plugins relative to the
-path of the main library. Consequently, a package manager can move
-the library and its plugins to a different location later --- as long
-as the relative path between the main library and the plugins is
-preserved. As a method of last resort, the user can specify an
-environment variable @verb{|LIBEXTRACTOR_PREFIX|}. If
address@hidden cannot locate a plugin, it will look in
address@hidden|LIBEXTRACTOR_PREFIX/lib/libextractor/|}.
-
-
address@hidden Installation on GNU/Linux
-
-Should work using the standard instructions without problems.
-
-
address@hidden Installation on FreeBSD
-
-Should work using the standard instructions without problems.
-
-
address@hidden Installation on OpenBSD
-
-OpenBSD 3.8 also doesn't have CODESET in @file{langinfo.h}. CODESET
-is used in @gnule{} in about three places. This causes problems
-during compilation.
-
-
address@hidden Installation on NetBSD
-
-No reports so far.
-
-
address@hidden Installation using MinGW
-
-Linking -lstdc++ with the provided libtool fails on Cygwin, this
-is a problem with libtool, there is unfortunately no flag to tell
-libtool how to do its job on Cygwin and it seems that it cannot be the
-default to set the library check to 'pass_all'. Patching libtool may
-help.
-
-Note: this is a rather dated report and may no longer apply.
-
-
address@hidden Installation on OS X
-
-libextractor has two installation methods on Mac OS X: it can be
-installed as a Mac OS X framework or with the standard
address@hidden/configure; make; make install} shell commands. The
-framework package is self-contained, but currently omits some of the
-extractor plugins that can be compiled in if libextractor is installed
-with @command{./configure; make; make install} (provided that the
-required dependencies exist.)
-
address@hidden Installing and uninstalling the framework
-
-The binary framework is distributed as a disk image
(@file{Extractor-x.x.xx.dmg}).
-Installation is done by opening the disk image and clicking
@file{Extractor.pkg}
-inside it. The Mac OS X installer application will then run. The framework
-is installed to the root volume's @file{/Library/Frameworks} folder and
installing
-will require admin privileges.
-
-The framework can be uninstalled by dragging
address@hidden/Library/Frameworks/Extractor.framework} cto the @file{Trash}.
-
-
address@hidden Using the framework
-
-In the framework, the @command{extract} command line tool can be found at
address@hidden/Library/Frameworks/Extractor.framework/Versions/Current/bin/extract}
-
-The framework can be used in software projects as a framework or as a dynamic
-library.
-
-When using the framework as a dynamic library in projects using autotools,
-one would most likely want to add
-"-I/Library/Frameworks/Extractor.framework/Versions/Current/include"
-to CPPFLAGS and
-"-L/Library/Frameworks/Extractor.framework/Versions/Current/lib"
-to LDFLAGS.
-
-
address@hidden Example for using the framework
-
address@hidden
address@hidden
-// hello.c
-#include <Extractor/extractor.h>
-
-int
-main (int argc, char **argv)
-{
- struct EXTRACTOR_PluginList *el;
- el = EXTRACTOR_plugin_load_defaults (EXTRACTOR_OPTION_DEFAULT_POLICY);
- // ...
- EXTRACTOR_plugin_remove_all (el);
- return 0;
-}
address@hidden verbatim
address@hidden example
-
-You can then compile the example using
-
address@hidden
-$ gcc -o hello hello.c -framework Extractor
address@hidden verbatim
-
address@hidden Example for using the dynamic library
-
address@hidden
address@hidden
-// hello.c
-#include <extractor.h>
-int main()
-{
- struct EXTRACTOR_PluginList *el;
- el = EXTRACTOR_plugin_load_defaults (EXTRACTOR_OPTION_DEFAULT_POLICY);
- // ...
- EXTRACTOR_plugin_remove_all (el);
- return 0;
-}
address@hidden verbatim
address@hidden example
-
-You can then compile the example using
-
address@hidden
-$ gcc -I/Library/Frameworks/Extractor.framework/Versions/Current/include \
- -o hello hello.c \
- -L/Library/Frameworks/Extractor.framework/Versions/Current/lib \
- -lextractor
address@hidden verbatim
-
-Notice the difference in the @code{#include} line.
-
-
-
-
-
-
address@hidden Note to package maintainers
-
-The suggested way to package GNU libextractor is to split it into
-roughly the following binary packages:
-
address@hidden @bullet
address@hidden
-libextractor (main library only, only hard dependency for other packages
depending on GNU libextractor)
address@hidden
-extract (command-line tool and man page extract.1)
address@hidden
-libextractor-dev (extractor.h header and man page libextractor.3)
address@hidden
-libextractor-doc (this manual)
address@hidden
-libextractor-plugins (plugins without external dependencies; recommended but
not required by extract and libextractor package)
address@hidden
-libextractor-plugin-XXX (plugin with dependency on libXXX, for example for
XXX=mpeg this would be @file{libextractor_mpeg.so})
address@hidden
-libextractor-plugins-all (meta package that requires all plugins except
experimental plugins)
address@hidden itemize
-
-This would enable minimal installations (i.e. for embedded systems) to
-not include any plugins, as well as moderate-size installations (that
-do not trigger GTK and X11) for systems that have limited resources.
-Right now, the MP4 plugin is experimental and does nothing and should
-thus never be included at all. The gstreamer plugin is experimental
-but largely works with the correct version of gstreamer and can thus
-be packaged (especially if the dependency is available on the target
-system) but should probably not be part of libextractor-plugins-all.
-
-
address@hidden Generalities
address@hidden Generalities
-
address@hidden Introduction to the ``extract'' command
-
-The @command{extract} command takes a list of file names as arguments,
-extracts meta data from each of those files and prints the result to
-the console. By default, @command{extract} will use all available
-plugins and print all (non-binary) meta data that is found.
-
-The set of plugins used by @command{extract} can be controlled using
-the ``-l'' and ``-n'' options. Use ``-n'' to not load all of the
-default plugins. Use ``-l NAME'' to specifically load a certain
-plugin. For example, specify ``-n -l mime'' to only use the MIME
-plugin.
-
-Using the ``-p'' option the output of @command{extract} can be limited
-to only certain keyword types. Similarly, using the ``-x'' option,
-certain keyword types can be excluded. A list of all known keyword
-types can be obtained using the ``-L'' option.
-
-The output format of @command{extract} can be influenced with the
-``-V'' (more verbose, lists filenames), ``-g'' (grep-friendly, all
-meta data on a single line per file) and ``-b'' (bibTeX style)
-options.
-
address@hidden Common usage examples for ``extract''
-
address@hidden
-$ extract test/test.jpg
-comment - (C) 2001 by Christian Grothoff, using gimp 1.2 1
-mimetype - image/jpeg
-
-$ extract -V -x comment test/test.jpg
-Keywords for file test/test.jpg:
-mimetype - image/jpeg
-
-$ extract -p comment test/test.jpg
-comment - (C) 2001 by Christian Grothoff, using gimp 1.2 1
-
-$ extract -nV -l png.so -p comment test/test.jpg test/test.png
-Keywords for file test/test.jpg:
-Keywords for file test/test.png:
-comment - Testing keyword extraction
address@hidden example
-
-
address@hidden Introduction to the libextractor library
-
-Each public symbol exported by @gnule{} has the prefix
address@hidden|EXTRACTOR_|}. All-caps names are used for constants. For the
-impatient, the minimal C code for using @gnule{} (on the
-executing binary itself) looks like this:
-
address@hidden
-#include <extractor.h>
-
-int
-main (int argc, char ** argv)
-{
- struct EXTRACTOR_PluginList *plugins
- = EXTRACTOR_plugin_add_defaults (EXTRACTOR_OPTION_DEFAULT_POLICY);
- EXTRACTOR_extract (plugins, argv[1],
- NULL, 0,
- &EXTRACTOR_meta_data_print, stdout);
- EXTRACTOR_plugin_remove_all (plugins);
- return 0;
-}
address@hidden verbatim
-
-The minimal API illustrated by this example is actually sufficient for
-many applications. The full external C API of @gnule{} is described
-in chapter @xref{Extracting meta data}. Bindings for other languages
-are described in chapter @xref{Language bindings}. The API for
-writing new plugins is described in chapter @xref{Writing new Plugins}.
-
address@hidden Extracting meta data
address@hidden Extracting meta data
-
-In order to extract meta data with @gnule{} you first need to
-load the respective plugins and then call the extraction API
-with the plugins and the data to process. This section
-documents how to load and unload plugins, the various types
-and formats in which meta data is returned to the application
-and finally the extraction API itself.
-
address@hidden
-* Plugin management:: How to load and unload plugins
-* Meta types:: About meta types
-* Meta formats:: About meta formats
-* Extracting:: How to use the extraction API
address@hidden menu
-
-
address@hidden Plugin management
address@hidden Plugin management
-
address@hidden reentrant
address@hidden concurrency
address@hidden threads
address@hidden thread-safety
address@hidden enum EXTRACTOR_Options
-
-Using @gnule{} from a multi-threaded parent process requires some
-care. The problem is that on most platforms @gnule{} starts
-sub-processes for the actual extraction work. This is useful to
-isolate the parent process from potential bugs; however, it can cause
-problems if the parent process is multi-threaded. The issue is that
-at the time of the fork, another thread of the application may hold a
-lock (i.e. in gettext or libc). That lock would then never be
-released in the child process (as the other thread is not present in
-the child process). As a result, the child process would then
-deadlock on trying to acquire the lock and never terminate. This has
-actually been observed with a lock in GNU gettext that is triggered by
-the plugin startup code when it interacts with libltdl.
-
-The problem can be solved by loading the plugins using the
address@hidden option, which will run @gnule{}
-in-process and thus avoid the locking issue. In this case, all of the
-functions for loading and unloading plugins, including
address@hidden|EXTRACTOR_plugin_add_defaults|} and
address@hidden|EXTRACTOR_plugin_remove_all|}, are thread-safe and reentrant.
-However, using the same plugin list from multiple threads at the same
-time is not safe.
-
-All plugin code is expected required to be reentrant and state-less,
-but due to the extensive use of 3rd party libraries this cannot
-be guaranteed.
-
-
address@hidden {C Struct} EXTRACTOR_PluginList
address@hidden struct EXTRACTOR_PluginList
-
-A plugin list represents a set of GNU libextractor plugins. Most of
-the GNU libextractor API is concerned with either constructing a
-plugin list or using it to extract meta data. The internal representation
-of the plugin list is of no concern to users or plugin developers.
address@hidden deftp
-
-
address@hidden void EXTRACTOR_plugin_remove_all (struct EXTRACTOR_PluginList
*plugins)
address@hidden EXTRACTOR_plugin_remove_all
-
-Unload all of the plugins in the given list.
address@hidden deftypefun
-
address@hidden {struct EXTRACTOR_PluginList *} EXTRACTOR_plugin_remove (struct
EXTRACTOR_PluginList *plugins, const char*name)
address@hidden EXTRACTOR_plugin_remove
-
-Unloads a particular plugin. The given name should be the short name of the
plugin, for example ``mime'' for the mime-type extractor or ``mpeg'' for the
MPEG extractor.
address@hidden deftypefun
-
address@hidden {struct EXTRACTOR_PluginList *} EXTRACTOR_plugin_add (struct
EXTRACTOR_PluginList *plugins, const char* name,const char* options, enum
EXTRACTOR_Options flags)
address@hidden EXTRACTOR_plugin_add
-
-Loads a particular plugin. The plugin is added to the existing list, which
can be NULL. The second argument specifies the name of the plugin (i.e.
``ogg''). The third argument can be NULL and specifies plugin-specific
options. Finally, the last argument specifies if the plugin should be executed
out-of-process (@code{EXTRACTOR_OPTION_DEFAULT_POLICY}) or not.
address@hidden deftypefun
-
address@hidden {struct EXTRACTOR_PluginList *} EXTRACTOR_plugin_add_config
(struct EXTRACTOR_PluginList *plugins, const char* config, enum
EXTRACTOR_Options flags)
address@hidden EXTRACTOR_plugin_add_config
-
-Loads and unloads plugins based on a configuration string, modifying the
existing list, which can be NULL. The string has the format
``[-]NAME(OPTIONS)@{:[-]NAME(OPTIONS)@}*''. Prefixing the plugin name with a
``-'' means that the plugin should be unloaded.
address@hidden deftypefun
-
address@hidden {struct EXTRACTOR_PluginList *} EXTRACTOR_plugin_add_defaults
(enum EXTRACTOR_Options flags)
address@hidden EXTRACTOR_plugin_add_defaults
-
-Loads all of the plugins in the plugin directory. This function is what most
@gnule{} applications should use to setup the plugins.
address@hidden deftypefun
-
-
-
address@hidden Meta types
address@hidden Meta types
-
-
address@hidden enum EXTRACTOR_MetaType
address@hidden EXTRACTOR_metatype_get_max
-
address@hidden|enum EXTRACTOR_MetaType|} is a C enum which defines a list of
over 100 different types of meta data. The total number can differ between
different @gnule{} releases; the maximum value for the current release can be
obtained using the @verb{|EXTRACTOR_metatype_get_max|} function. All values in
this enumeration are of the form @verb{|EXTRACTOR_METATYPE_XXX|}.
-
address@hidden {const char *} EXTRACTOR_metatype_to_string (enum
EXTRACTOR_MetaType type)
address@hidden EXTRACTOR_metatype_to_string
address@hidden gettext
address@hidden internationalization
-
-The function @verb{|EXTRACTOR_metatype_to_string|} can be used to obtain a
short English string @samp{s} describing the meta data type. The string can be
translated into other languages using GNU gettext with the domain set to
@gnule{} (@verb{|dgettext("libextractor", s)|}).
address@hidden deftypefun
-
address@hidden {const char *} EXTRACTOR_metatype_to_description (enum
EXTRACTOR_MetaType type)
address@hidden EXTRACTOR_metatype_to_description
address@hidden gettext
address@hidden internationalization
-
-The function @verb{|EXTRACTOR_metatype_to_description|} can be used to obtain
a longer English string @samp{s} describing the meta data type. The
description may be empty if the short description returned by
@code{EXTRACTOR_metatype_to_string} is already comprehensive. The string can
be translated into other languages using GNU gettext with the domain set to
@gnule{} (@verb{|dgettext("libextractor", s)|}).
address@hidden deftypefun
-
-
-
address@hidden Meta formats
address@hidden Meta formats
-
address@hidden enum EXTRACTOR_MetaFormat
-
address@hidden|enum EXTRACTOR_MetaFormat|} is a C enum which defines on a high
level how the extracted meta data is represented. Currently, the library uses
three formats: UTF-8 strings, C strings and binary data. A fourth value,
@code{EXTRACTOR_METAFORMAT_UNKNOWN} is defined but not used. UTF-8 strings are
0-terminated strings that have been converted to UTF-8. The format code is
@code{EXTRACTOR_METAFORMAT_UTF8}. Ideally, most text meta data will be of this
format. Some file formats fail to specify the encoding used for the text. In
this case, the text cannot be converted to UTF-8. However, the meta data is
still known to be 0-terminated and presumably human-readable. In this case,
the format code used is @code{EXTRACTOR_METAFORMAT_C_STRING}; however, this
should not be understood to mean that the encoding is the same as that used by
the C compiler. Finally, for binary data (mostly images), the format
@code{EXTRACTOR_METAFORMAT_BINARY} is used.
-
-Naturally this is not a precise description of the meta format. Plugins can
provide a more precise description (if known) by providing the respective mime
type of the meta data. For example, binary image meta data could be also
tagged as ``image/png'' and normal text would typically be tagged as
``text/plain''.
-
-
-
address@hidden Extracting
address@hidden Extracting
-
address@hidden {Function Pointer} int (*EXTRACTOR_MetaDataProcessor)(void *cls,
const char *plugin_name, enum EXTRACTOR_MetaType type, enum
EXTRACTOR_MetaFormat format, const char *data_mime_type, const char *data,
size_t data_len)
address@hidden EXTRACTOR_MetaDataProcessor
-
-Type of a function that libextractor calls for each meta data item found.
-
address@hidden @var
-
address@hidden cls
-closure (user-defined)
-
address@hidden plugin_name
-name of the plugin that produced this value; special values can be used (i.e.
'<zlib>' for zlib being used in the main libextractor library and yielding meta
data);
-
address@hidden type
-libextractor-type describing the meta data;
-
address@hidden format basic
-format information about data
-
address@hidden data_mime_type
-mime-type of data (not of the original file); can be NULL (if mime-type is not
known);
-
address@hidden data
-actual meta-data found
-
address@hidden data_len
-number of bytes in data
-
address@hidden table
-
-Return 0 to continue extracting, 1 to abort.
address@hidden deftypefn
-
-
-
address@hidden void EXTRACTOR_extract (struct EXTRACTOR_PluginList *plugins,
const char *filename, const void *data, size_t size,
EXTRACTOR_MetaDataProcessor proc, void *proc_cls)
address@hidden EXTRACTOR_extract
address@hidden reentrant
address@hidden concurrency
address@hidden threads
address@hidden thread-safety
-
-This is the main function for extracting keywords with @gnule{}. The first
argument is a plugin list which specifies the set of plugins that should be
used for extracting meta data. The @samp{filename} argument is optional and
can be used to specify the name of a file to process. If @samp{filename} is
NULL, then the @samp{data} argument must point to the in-memory data to extract
meta data from. If @samp{filename} is non-NULL, @samp{data} can be NULL. If
@samp{data} is non-null, then @samp{size} is the size of @samp{data} in bytes.
Otherwise @samp{size} should be zero. For each meta data item found, GNU
libextractor will call the @samp{proc} function, passing @samp{proc_cls} as the
first argument to @samp{proc}. The other arguments to @samp{proc} depend on
the specific meta data found.
-
address@hidden SIGBUS
address@hidden bus error
-Meta data extraction should never really fail --- at worst, @gnule{} should
not call @samp{proc} with any meta data. By design, @gnule{} should never crash
or leak memory, even given corrupt files as input. Note however, that running
@gnule{} on a corrupt file system (or incorrectly @verb{|mmap|}ed files) can
result in the operating system sending a SIGBUS (bus error) to the process.
While @gnule{} runs plugins out-of-process, it first maps the file into memory
and then attempts to decompress it. During decompression it is possible to
encounter a SIGBUS. @gnule{} will @emph{not} attempt to catch this signal and
your application is likely to crash. Note again that this should only happen
if the file @emph{system} is corrupt (not if individual files are corrupt). If
this is not acceptable, you might want to consider running @gnule{} itself also
out-of-process (as done, for example, by
@url{http://grothoff.org/christian/doodle/,doodle}).
-
address@hidden deftypefun
-
-
address@hidden Language bindings
address@hidden Language bindings
address@hidden Java
address@hidden Mono
address@hidden Perl
address@hidden Python
address@hidden PHP
address@hidden Ruby
-
address@hidden works immediately with C and C++ code. Bindings for Java, Mono,
Ruby, Perl, PHP and Python are available for download from the main @gnule{}
website. Documentation for these bindings (if available) is part of the
downloads for the respective binding. In all cases, a full installation of the
C library is required before the binding can be installed.
-
address@hidden Java
-
-Compiling the GNU libextractor Java binding follows the usual process of
-running @command{configure} and @command{make}. The result will be a
-shared C library @file{libextractor_java.so} with the native code and
-a JAR file (installed to @file{$PREFIX/share/java/libextractor.java}).
-
-A minimal example for using GNU libextractor's Java binding would look
-like this:
address@hidden
-import org.gnu.libextractor.*;
-import java.util.ArrayList;
-
-public static void main(String[] args) {
- Extractor ex = Extractor.getDefault();
- for (int i=0;i<args.length;i++) {
- ArrayList keywords = ex.extract(args[i]);
- System.out.println("Keywords for " + args[i] + ":");
- for (int j=0;j<keywords.size();j++)
- System.out.println(keywords.get(j));
- }
-}
address@hidden verbatim
-
-The GNU libextractor library and the @file{libextractor_java.so} JNI binding
-have to be in the library search path for this to work. Furthermore, the
address@hidden file should be on the classpath.
-
-Note that the API does not use Java 5 style generics in order to work
-with older versions of Java.
-
address@hidden Mono
-
-his binding is undocumented at this point.
-
address@hidden Perl
-
-This binding is undocumented at this point.
-
address@hidden Python
-
-This binding is undocumented at this point.
-
address@hidden PHP
-
-This binding is undocumented at this point.
-
address@hidden Ruby
-
-This binding is undocumented at this point.
-
-
-
address@hidden Utility functions
address@hidden Utility functions
-
address@hidden reentrant
address@hidden concurrency
address@hidden threads
address@hidden thread-safety
-This chapter describes various utility functions for @gnule{} usage. All of
the functions are reentrant.
-
address@hidden
-* Utility Constants::
-* Meta data printing::
address@hidden menu
-
address@hidden Utility Constants
address@hidden Utility Constants
-
address@hidden EXTRACTOR_VERSION
-The constant @verb{|EXTRACTOR_VERSION|} is a hexadecimal
-representation of the version number of the installed libextractor
-header. The hexadecimal format is 0xAABBCCDD where AA is the major
-version (so far always 0), BB is the minor version, CC is the revision
-and DD the patch number. For example, for version 0.5.18, we would
-have AA=0, BB=5, CC=18 and DD=0. Minor releases such as 0.5.18a or
-significant changes in unreleased versions would be marked with DD=1
-or higher.
-
-
address@hidden Meta data printing
address@hidden Meta data printing
-
-
address@hidden EXTRACTOR_meta_data_print
-The @verb{|EXTRACTOR_meta_data_print|} is a simple function which prints the
meta data found with libextractor to a file. The function is mostly useful for
debugging and as an example for how to manipulate the keyword list and can be
passed as the @samp{proc} argument to @code{EXTRACTOR_extract}. The file to
print to should be passed as @samp{proc_cls} (which must be of type @code{FILE
*}), for example @code{stdout}.
-
-
-
address@hidden Existing Plugins
address@hidden Existing Plugins
-
address@hidden @bullet
address@hidden
-ARCHIVE (using libarchive)
address@hidden
-DVI
address@hidden
-EXIV2 (using libexiv2, 0.23 or later preferred)
address@hidden
-FLAC (using libFLAC)
address@hidden
-GIF (using libgif)
address@hidden
-GSTREAMER (using libgstreamer v1.0 or later)
address@hidden
-HTML (using libtidy)
address@hidden
-IT
address@hidden
-JPEG (using libjpeg v8 or later)
address@hidden
-MAN
address@hidden
-MIDI (using libsmf)
address@hidden
-MIME (using libmagic)
address@hidden
-MPEG (using libmpeg2)
address@hidden
-NSF
address@hidden
-NSFE
address@hidden
-ODF
address@hidden
-OLE2 (with libgsf)
address@hidden
-OGG (with libogg)
address@hidden
-PNG
address@hidden
-PS
address@hidden
-RIFF
address@hidden
-RPM (using librpm)
address@hidden
-S3M
address@hidden
-SID
address@hidden
-ThumbnailFFMPEG (using libavformat and related libav-libraries, including
libswscale)
address@hidden
-ThumbnailGtk (using libgtk)
address@hidden
-TIFF (with libtiff, tested with v4)
address@hidden
-WAV
address@hidden
-XM
address@hidden
-ZIP
address@hidden itemize
-
address@hidden and @file{bzip2} compressed versions of these formats are
-also supported (as well as meta data embedded by @file{gzip} itself)
-if zlib or libbz2 are available.
-
address@hidden Writing new Plugins
address@hidden Writing new Plugins
-
-Writing a new plugin for libextractor usually requires writing of or
-interfacing with an actual parser for a specific format. How this is
-can be accomplished depends on the format and cannot be specified in
-general. However, care should be taken for the code to be reentrant
-and highly fault-tolerant, especially with respect to malformed
-inputs.
-
-Plugins should start by verifying that the header of the data matches
-the specific format and immediately return if that is not the case.
-Even if the header matches the expected file format, plugins must not
-assume that the remainder of the file is well formed.
-
-The plugin library must be called libextractor_XXX.so, where XXX
-denotes the file format of the plugin. The library must export a
-method @verb{|libextractor_XXX_extract_method|}, with the following
-signature:
address@hidden
-void
-EXTRACTOR_XXX_extract_method (struct EXTRACTOR_ExtractContext *ec);
address@hidden verbatim
-
address@hidden contains various information the plugin may need for its
-execution. Most importantly, it contains functions for reading
-(``read'') and seeking (``seek'') the input data and for returning
-extracted data (``proc''). The ``config'' member can contain
-additional configuration options. ``proc'' should be called on
-each meta data item found. If ``proc'' returns non-zero,
-processing should be aborted (if possible).
-
-In order to test new plugins, the @file{extract} command can be run
-with the options ``-ni'' and ``-l XXX'' . This will run the plugin
-in-process (making it easier to debug) and without any of the other
-plugins.
-
-
address@hidden Example for a minimal extract method
-
-The following example shows how a plugin can return the mime type of
-a file.
address@hidden
address@hidden
-void
-EXTRACTOR_mymime_extract (struct EXTRACTOR_ExtractContext *ec)
-{
- void *data;
- ssize_t data_size,
-
- if (-1 == (data_size = ec->read (ec->cls, &data, 4)))
- return; /* read error */
- if (data_size < 4)
- return; /* file too small */
- if (0 != memcmp (data, "\177ELF", 4))
- return; /* not ELF */
- if (0 != ec->proc (ec->cls,
- "mymime",
- EXTRACTOR_METATYPE_MIMETYPE,
- EXTRACTOR_METAFORMAT_UTF8,
- "text/plain",
- "application/x-executable",
- 1 + strlen("application/x-executable")))
- return;
- /* more calls to 'proc' here as needed */
-}
address@hidden verbatim
address@hidden example
-
-
address@hidden Internal utility functions
address@hidden Internal utility functions
-
-Some plugins link against the @code{libextractor_common} library which
-provides common abstractions needed by many plugins. This section
-documents this internal API for plugin developers. Note that the headers
-for this library are (intentionally) not installed: we do not consider
-this API stable and it should hence only be used by plugins that are
-build and shipped with GNU libextractor. Third-party plugins should
-not use it.
-
address@hidden defines various conversion functions for
-numbers (in particular, byte-order conversion for floating point
-numbers).
-
address@hidden defines an API for accessing compressed files.
-
address@hidden provides an interpreter for unpacking structs of integer
-numbers from streams and converting from big or little endian to host
-byte order at the same time.
-
address@hidden provides a function for character set conversion described
-below.
-
address@hidden {char *} EXTRACTOR_common_convert_to_utf8 (const char *input,
size_t len, const char *charset)
address@hidden UTF-8
address@hidden character set
address@hidden EXTRACTOR_common_convert_to_utf8
-Various @gnule{} plugins make use of the internal
address@hidden header which defines a function
-
address@hidden|EXTRACTOR_common_convert_to_utf8|} which can be used to easily
convert text from
-any character set to UTF-8. This conversion is important since the
-linked list of keywords that is returned by @gnule{} is
-expected to contain only UTF-8 strings. Naturally, proper conversion
-may not always be possible since some file formats fail to specify the
-character set. In that case, it is often better to not convert at
-all.
-
-The arguments to @verb{|EXTRACTOR_common_convert_to_utf8|} are the input
string (which
-does @emph{not} have to be zero-terminated), the length of the input
-string, and the character set (which @emph{must} be zero-terminated).
-Which character sets are supported depends on the platform, a list can
-generally be obtained using the @command{iconv -l} command. The
-return value from @verb{|EXTRACTOR_common_convert_to_utf8|} is a
zero-terminated string
-in UTF-8 format. The responsibility to free the string is with the
-caller, so storing the string in the keyword list is acceptable.
address@hidden deftypefun
-
-
-
-
-
address@hidden Reporting bugs
address@hidden Reporting bugs
-
address@hidden bug
address@hidden uses the @url{https://gnunet.org/bugs/,Mantis bugtracking
-system}. If possible, please report bugs there. You can also e-mail
-the @gnule{} mailinglist at @url{libextractor@@gnu.org}.
-
-
-
address@hidden **********************************************************
address@hidden ******************* Appendices *************************
address@hidden **********************************************************
-
address@hidden GNU Free Documentation License
address@hidden GNU Free Documentation License
-
address@hidden fdl-1.3.texi
-
-
address@hidden Concept Index
address@hidden Concept Index
-
address@hidden cp
-
address@hidden Function and Data Index
address@hidden Function and Data Index
-
address@hidden fn
-
address@hidden Type Index
address@hidden Type Index
-
address@hidden tp
-
address@hidden
Copied: Extractor/doc/libextractor.texi (from rev 23702,
Extractor/doc/extractor.texi)
===================================================================
--- Extractor/doc/libextractor.texi (rev 0)
+++ Extractor/doc/libextractor.texi 2012-09-08 08:32:35 UTC (rev 23703)
@@ -0,0 +1,1019 @@
+\input texinfo @c -*- Texinfo -*-
address@hidden % The structure of this document is based on the
address@hidden % Texinfo manual from libgcrypt by Werner Koch and
address@hidden % and Moritz Schulte.
address@hidden %**start of header
address@hidden extractor.info
address@hidden version.texi
address@hidden The GNU libextractor Reference Manual
address@hidden Unify some of the indices.
address@hidden %**end of header
address@hidden
+This manual is for GNU libextractor
+(version @value{VERSION}, @value{UPDATED}), a library for metadata
+extraction.
+
+Copyright @copyright{} 2007, 2010, 2012 Christian Grothoff
+
address@hidden
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.3
+or any later version published by the Free Software Foundation;
+with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
+Texts. A copy of the license is included in the section entitled ``GNU
+Free Documentation License''.
address@hidden quotation
address@hidden copying
+
address@hidden Software libraries
address@hidden
+* Libextractor: (extractor). Metadata extraction library.
address@hidden direntry
+
+
+
address@hidden
address@hidden Titlepage
address@hidden
address@hidden
address@hidden The GNU libextractor Reference Manual
address@hidden Version @value{VERSION}
address@hidden @value{UPDATED}
address@hidden Christian Grothoff (@email{christian@@grothoff.org})
+
address@hidden
address@hidden 0pt plus 1filll
address@hidden
address@hidden titlepage
+
+
address@hidden
address@hidden
+
+
address@hidden gnu{}
address@hidden
address@hidden macro
+
address@hidden gpl{}
address@hidden
address@hidden macro
+
address@hidden api{}
address@hidden
address@hidden macro
+
address@hidden cfunction{arg}
address@hidden()}
address@hidden macro
+
address@hidden mynull{}
address@hidden
address@hidden macro
+
address@hidden gnule{}
address@hidden libextractor}
address@hidden macro
+
+
address@hidden
address@hidden Top
address@hidden The GNU libextractor Reference Manual
address@hidden
address@hidden ifnottex
+
address@hidden
+* Introduction:: What is @gnule{}.
+* Preparation:: What you should do before using the library.
+* Generalities:: General library functions and data types.
+* Extracting meta data:: How to use @gnule{} to obtain meta data.
+* Language bindings:: How to use @gnule{} from languages other than
C.
+* Utility functions:: Utility functions of @gnule{}.
+* Existing Plugins:: What plugins are available.
+* Writing new Plugins:: How to write new plugins for @gnule{}.
+* Internal utility functions:: Utility functions of @gnule{} for writing
plugins.
+* Reporting bugs:: How to report bugs or request new features.
+
+Appendices
+
+* GNU Free Documentation License:: Copying this manual.
+
+Indices
+
+* Concept Index:: Index of concepts and programs.
+* Function and Data Index:: Index of functions, variables and data types.
+* Type Index:: Index of data types.
+
address@hidden menu
+
+
+
address@hidden **********************************************************
address@hidden ******************* Introduction ***********************
address@hidden **********************************************************
address@hidden Introduction
address@hidden Introduction
+
address@hidden error handling
address@hidden is GNU's library for extracting meta data from
+files. Meta data includes format information (such as mime type,
+image dimensions, color depth, recording frequency), content
+descriptions (such as document title or document description) and
+copyright information (such as license, author and contributors).
+Meta data extraction is an inherently uncertain business --- a parse
+error can be a corrupt file, an incompatibility in the file format
+version, an entirely different file format or a bug in the parser. As
+a result of this uncertainty, @gnule{} deliberately
+avoids to ever report any errors. Unexpected file contents simply
+result in less or possibly no meta data being extracted.
+
address@hidden plugin
address@hidden uses plugins to handle various file formats.
+Technically a plugin can support multiple file formats; however, most
+plugins only support one particular format. By default,
address@hidden will use all plugins that are available and found
+in the plugin installation directory. Applications can
+request the use of only specific plugins or the exclusion of
+certain plugins.
+
address@hidden is distributed with the @command{extract}
address@hidden distributions ship @command{extract} in a
+seperate package.} which is a command-line tool for extracting
+meta data. @command{extract} is given a list of filenames and
+prints the resulting meta data to the console. The @command{extract}
+source code also serves as an advanced example for how to use
address@hidden
+
+This manual focuses on providing documentation for writing software
+with @gnule{}. The only relevant parts for end-users
+are the chapter on compiling and installing @gnule{}
+(@xref{Preparation}.). Also, the chapter on existing plugins maybe of
+interest (@xref{Existing Plugins}.). Additional documentation for
+end-users can be find in the man page on @command{extract} (using
address@hidden|man extract|}).
+
address@hidden license
address@hidden is licensed under the GNU General Public License,
+specifically, since version 0.7, @gnule{} is licensed under GPLv3
address@hidden any later version}.
+
address@hidden Preparation
address@hidden Preparation
+
+This chapter first describes the general build instructions that
+should apply to all systems. Specific instructions for known problems
+for particular platforms are then described in individual sections
+afterwards.
+
+Compiling @gnule{} follows the standard GNU autotools build process
+using @command{configure} and @command{make}. For details on the GNU
+autotools build process, read the @file{INSTALL} file and query
address@hidden|./configure --help|} for additional options.
+
address@hidden has various dependencies, most of which are optional.
+Instead of specifying the names of the software packages, we
+will give the list in terms of the names of the respective
+Debian (unstable) packages that should be installed.
+
+You absolutely need:
+
address@hidden @bullet
address@hidden
+libtool
address@hidden
+gcc
address@hidden
+make
address@hidden
+g++
address@hidden
+libltdl7-dev
address@hidden itemize
+
+Recommended dependencies are:
address@hidden @bullet
address@hidden
+zlib1g-dev
address@hidden
+libbz2-dev
address@hidden
+libgif-dev
address@hidden
+libvorbis-dev
address@hidden
+libflac-dev
address@hidden
+libmpeg2-4-dev
address@hidden
+librpm-dev
address@hidden
+libgtk2.0-dev
address@hidden
+libgsf-1-dev
address@hidden
+libqt4-dev
address@hidden
+libpoppler-dev
address@hidden
+libexiv2-dev
address@hidden
+libavformat-dev
address@hidden
+libswscale-dev
address@hidden itemize
+
+For Subversion access and compilation one also needs:
address@hidden @bullet
address@hidden
+subversion
address@hidden
+autoconf
address@hidden
+automake
address@hidden itemize
+
+Please notify us if we missed some dependencies (note that the list is
+supposed to only list direct dependencies, not transitive
+dependencies).
+
+Once you have compiled and installed @gnule{}, you should have a file
address@hidden installed in your @file{include/} directory. This
+file should be the starting point for your C and C++ development with
address@hidden The build process also installs the @file{extract} binary and
+man pages for @file{extract} and @gnule{}. The @file{extract} man page
+documents the @file{extract} tool. The @gnule{} man page gives a brief
+summary of the C API for @gnule{}.
+
address@hidden packageing
address@hidden directory structure
address@hidden plugin
address@hidden environment variables
address@hidden LIBEXTRACTOR_PREFIX
+When you install @gnule{}, various plugins will be
+installed in the @file{lib/libextractor/} directory. The main library
+will be installed as @file{lib/libextractor.so}. Note that
address@hidden will attempt to find the plugins relative to the
+path of the main library. Consequently, a package manager can move
+the library and its plugins to a different location later --- as long
+as the relative path between the main library and the plugins is
+preserved. As a method of last resort, the user can specify an
+environment variable @verb{|LIBEXTRACTOR_PREFIX|}. If
address@hidden cannot locate a plugin, it will look in
address@hidden|LIBEXTRACTOR_PREFIX/lib/libextractor/|}.
+
+
address@hidden Installation on GNU/Linux
+
+Should work using the standard instructions without problems.
+
+
address@hidden Installation on FreeBSD
+
+Should work using the standard instructions without problems.
+
+
address@hidden Installation on OpenBSD
+
+OpenBSD 3.8 also doesn't have CODESET in @file{langinfo.h}. CODESET
+is used in @gnule{} in about three places. This causes problems
+during compilation.
+
+
address@hidden Installation on NetBSD
+
+No reports so far.
+
+
address@hidden Installation using MinGW
+
+Linking -lstdc++ with the provided libtool fails on Cygwin, this
+is a problem with libtool, there is unfortunately no flag to tell
+libtool how to do its job on Cygwin and it seems that it cannot be the
+default to set the library check to 'pass_all'. Patching libtool may
+help.
+
+Note: this is a rather dated report and may no longer apply.
+
+
address@hidden Installation on OS X
+
+libextractor has two installation methods on Mac OS X: it can be
+installed as a Mac OS X framework or with the standard
address@hidden/configure; make; make install} shell commands. The
+framework package is self-contained, but currently omits some of the
+extractor plugins that can be compiled in if libextractor is installed
+with @command{./configure; make; make install} (provided that the
+required dependencies exist.)
+
address@hidden Installing and uninstalling the framework
+
+The binary framework is distributed as a disk image
(@file{Extractor-x.x.xx.dmg}).
+Installation is done by opening the disk image and clicking
@file{Extractor.pkg}
+inside it. The Mac OS X installer application will then run. The framework
+is installed to the root volume's @file{/Library/Frameworks} folder and
installing
+will require admin privileges.
+
+The framework can be uninstalled by dragging
address@hidden/Library/Frameworks/Extractor.framework} cto the @file{Trash}.
+
+
address@hidden Using the framework
+
+In the framework, the @command{extract} command line tool can be found at
address@hidden/Library/Frameworks/Extractor.framework/Versions/Current/bin/extract}
+
+The framework can be used in software projects as a framework or as a dynamic
+library.
+
+When using the framework as a dynamic library in projects using autotools,
+one would most likely want to add
+"-I/Library/Frameworks/Extractor.framework/Versions/Current/include"
+to CPPFLAGS and
+"-L/Library/Frameworks/Extractor.framework/Versions/Current/lib"
+to LDFLAGS.
+
+
address@hidden Example for using the framework
+
address@hidden
address@hidden
+// hello.c
+#include <Extractor/extractor.h>
+
+int
+main (int argc, char **argv)
+{
+ struct EXTRACTOR_PluginList *el;
+ el = EXTRACTOR_plugin_load_defaults (EXTRACTOR_OPTION_DEFAULT_POLICY);
+ // ...
+ EXTRACTOR_plugin_remove_all (el);
+ return 0;
+}
address@hidden verbatim
address@hidden example
+
+You can then compile the example using
+
address@hidden
+$ gcc -o hello hello.c -framework Extractor
address@hidden verbatim
+
address@hidden Example for using the dynamic library
+
address@hidden
address@hidden
+// hello.c
+#include <extractor.h>
+int main()
+{
+ struct EXTRACTOR_PluginList *el;
+ el = EXTRACTOR_plugin_load_defaults (EXTRACTOR_OPTION_DEFAULT_POLICY);
+ // ...
+ EXTRACTOR_plugin_remove_all (el);
+ return 0;
+}
address@hidden verbatim
address@hidden example
+
+You can then compile the example using
+
address@hidden
+$ gcc -I/Library/Frameworks/Extractor.framework/Versions/Current/include \
+ -o hello hello.c \
+ -L/Library/Frameworks/Extractor.framework/Versions/Current/lib \
+ -lextractor
address@hidden verbatim
+
+Notice the difference in the @code{#include} line.
+
+
+
+
+
+
address@hidden Note to package maintainers
+
+The suggested way to package GNU libextractor is to split it into
+roughly the following binary packages:
+
address@hidden @bullet
address@hidden
+libextractor (main library only, only hard dependency for other packages
depending on GNU libextractor)
address@hidden
+extract (command-line tool and man page extract.1)
address@hidden
+libextractor-dev (extractor.h header and man page libextractor.3)
address@hidden
+libextractor-doc (this manual)
address@hidden
+libextractor-plugins (plugins without external dependencies; recommended but
not required by extract and libextractor package)
address@hidden
+libextractor-plugin-XXX (plugin with dependency on libXXX, for example for
XXX=mpeg this would be @file{libextractor_mpeg.so})
address@hidden
+libextractor-plugins-all (meta package that requires all plugins except
experimental plugins)
address@hidden itemize
+
+This would enable minimal installations (i.e. for embedded systems) to
+not include any plugins, as well as moderate-size installations (that
+do not trigger GTK and X11) for systems that have limited resources.
+Right now, the MP4 plugin is experimental and does nothing and should
+thus never be included at all. The gstreamer plugin is experimental
+but largely works with the correct version of gstreamer and can thus
+be packaged (especially if the dependency is available on the target
+system) but should probably not be part of libextractor-plugins-all.
+
+
address@hidden Generalities
address@hidden Generalities
+
address@hidden Introduction to the ``extract'' command
+
+The @command{extract} command takes a list of file names as arguments,
+extracts meta data from each of those files and prints the result to
+the console. By default, @command{extract} will use all available
+plugins and print all (non-binary) meta data that is found.
+
+The set of plugins used by @command{extract} can be controlled using
+the ``-l'' and ``-n'' options. Use ``-n'' to not load all of the
+default plugins. Use ``-l NAME'' to specifically load a certain
+plugin. For example, specify ``-n -l mime'' to only use the MIME
+plugin.
+
+Using the ``-p'' option the output of @command{extract} can be limited
+to only certain keyword types. Similarly, using the ``-x'' option,
+certain keyword types can be excluded. A list of all known keyword
+types can be obtained using the ``-L'' option.
+
+The output format of @command{extract} can be influenced with the
+``-V'' (more verbose, lists filenames), ``-g'' (grep-friendly, all
+meta data on a single line per file) and ``-b'' (bibTeX style)
+options.
+
address@hidden Common usage examples for ``extract''
+
address@hidden
+$ extract test/test.jpg
+comment - (C) 2001 by Christian Grothoff, using gimp 1.2 1
+mimetype - image/jpeg
+
+$ extract -V -x comment test/test.jpg
+Keywords for file test/test.jpg:
+mimetype - image/jpeg
+
+$ extract -p comment test/test.jpg
+comment - (C) 2001 by Christian Grothoff, using gimp 1.2 1
+
+$ extract -nV -l png.so -p comment test/test.jpg test/test.png
+Keywords for file test/test.jpg:
+Keywords for file test/test.png:
+comment - Testing keyword extraction
address@hidden example
+
+
address@hidden Introduction to the libextractor library
+
+Each public symbol exported by @gnule{} has the prefix
address@hidden|EXTRACTOR_|}. All-caps names are used for constants. For the
+impatient, the minimal C code for using @gnule{} (on the
+executing binary itself) looks like this:
+
address@hidden
+#include <extractor.h>
+
+int
+main (int argc, char ** argv)
+{
+ struct EXTRACTOR_PluginList *plugins
+ = EXTRACTOR_plugin_add_defaults (EXTRACTOR_OPTION_DEFAULT_POLICY);
+ EXTRACTOR_extract (plugins, argv[1],
+ NULL, 0,
+ &EXTRACTOR_meta_data_print, stdout);
+ EXTRACTOR_plugin_remove_all (plugins);
+ return 0;
+}
address@hidden verbatim
+
+The minimal API illustrated by this example is actually sufficient for
+many applications. The full external C API of @gnule{} is described
+in chapter @xref{Extracting meta data}. Bindings for other languages
+are described in chapter @xref{Language bindings}. The API for
+writing new plugins is described in chapter @xref{Writing new Plugins}.
+
address@hidden Extracting meta data
address@hidden Extracting meta data
+
+In order to extract meta data with @gnule{} you first need to
+load the respective plugins and then call the extraction API
+with the plugins and the data to process. This section
+documents how to load and unload plugins, the various types
+and formats in which meta data is returned to the application
+and finally the extraction API itself.
+
address@hidden
+* Plugin management:: How to load and unload plugins
+* Meta types:: About meta types
+* Meta formats:: About meta formats
+* Extracting:: How to use the extraction API
address@hidden menu
+
+
address@hidden Plugin management
address@hidden Plugin management
+
address@hidden reentrant
address@hidden concurrency
address@hidden threads
address@hidden thread-safety
address@hidden enum EXTRACTOR_Options
+
+Using @gnule{} from a multi-threaded parent process requires some
+care. The problem is that on most platforms @gnule{} starts
+sub-processes for the actual extraction work. This is useful to
+isolate the parent process from potential bugs; however, it can cause
+problems if the parent process is multi-threaded. The issue is that
+at the time of the fork, another thread of the application may hold a
+lock (i.e. in gettext or libc). That lock would then never be
+released in the child process (as the other thread is not present in
+the child process). As a result, the child process would then
+deadlock on trying to acquire the lock and never terminate. This has
+actually been observed with a lock in GNU gettext that is triggered by
+the plugin startup code when it interacts with libltdl.
+
+The problem can be solved by loading the plugins using the
address@hidden option, which will run @gnule{}
+in-process and thus avoid the locking issue. In this case, all of the
+functions for loading and unloading plugins, including
address@hidden|EXTRACTOR_plugin_add_defaults|} and
address@hidden|EXTRACTOR_plugin_remove_all|}, are thread-safe and reentrant.
+However, using the same plugin list from multiple threads at the same
+time is not safe.
+
+All plugin code is expected required to be reentrant and state-less,
+but due to the extensive use of 3rd party libraries this cannot
+be guaranteed.
+
+
address@hidden {C Struct} EXTRACTOR_PluginList
address@hidden struct EXTRACTOR_PluginList
+
+A plugin list represents a set of GNU libextractor plugins. Most of
+the GNU libextractor API is concerned with either constructing a
+plugin list or using it to extract meta data. The internal representation
+of the plugin list is of no concern to users or plugin developers.
address@hidden deftp
+
+
address@hidden void EXTRACTOR_plugin_remove_all (struct EXTRACTOR_PluginList
*plugins)
address@hidden EXTRACTOR_plugin_remove_all
+
+Unload all of the plugins in the given list.
address@hidden deftypefun
+
address@hidden {struct EXTRACTOR_PluginList *} EXTRACTOR_plugin_remove (struct
EXTRACTOR_PluginList *plugins, const char*name)
address@hidden EXTRACTOR_plugin_remove
+
+Unloads a particular plugin. The given name should be the short name of the
plugin, for example ``mime'' for the mime-type extractor or ``mpeg'' for the
MPEG extractor.
address@hidden deftypefun
+
address@hidden {struct EXTRACTOR_PluginList *} EXTRACTOR_plugin_add (struct
EXTRACTOR_PluginList *plugins, const char* name,const char* options, enum
EXTRACTOR_Options flags)
address@hidden EXTRACTOR_plugin_add
+
+Loads a particular plugin. The plugin is added to the existing list, which
can be NULL. The second argument specifies the name of the plugin (i.e.
``ogg''). The third argument can be NULL and specifies plugin-specific
options. Finally, the last argument specifies if the plugin should be executed
out-of-process (@code{EXTRACTOR_OPTION_DEFAULT_POLICY}) or not.
address@hidden deftypefun
+
address@hidden {struct EXTRACTOR_PluginList *} EXTRACTOR_plugin_add_config
(struct EXTRACTOR_PluginList *plugins, const char* config, enum
EXTRACTOR_Options flags)
address@hidden EXTRACTOR_plugin_add_config
+
+Loads and unloads plugins based on a configuration string, modifying the
existing list, which can be NULL. The string has the format
``[-]NAME(OPTIONS)@{:[-]NAME(OPTIONS)@}*''. Prefixing the plugin name with a
``-'' means that the plugin should be unloaded.
address@hidden deftypefun
+
address@hidden {struct EXTRACTOR_PluginList *} EXTRACTOR_plugin_add_defaults
(enum EXTRACTOR_Options flags)
address@hidden EXTRACTOR_plugin_add_defaults
+
+Loads all of the plugins in the plugin directory. This function is what most
@gnule{} applications should use to setup the plugins.
address@hidden deftypefun
+
+
+
address@hidden Meta types
address@hidden Meta types
+
+
address@hidden enum EXTRACTOR_MetaType
address@hidden EXTRACTOR_metatype_get_max
+
address@hidden|enum EXTRACTOR_MetaType|} is a C enum which defines a list of
over 100 different types of meta data. The total number can differ between
different @gnule{} releases; the maximum value for the current release can be
obtained using the @verb{|EXTRACTOR_metatype_get_max|} function. All values in
this enumeration are of the form @verb{|EXTRACTOR_METATYPE_XXX|}.
+
address@hidden {const char *} EXTRACTOR_metatype_to_string (enum
EXTRACTOR_MetaType type)
address@hidden EXTRACTOR_metatype_to_string
address@hidden gettext
address@hidden internationalization
+
+The function @verb{|EXTRACTOR_metatype_to_string|} can be used to obtain a
short English string @samp{s} describing the meta data type. The string can be
translated into other languages using GNU gettext with the domain set to
@gnule{} (@verb{|dgettext("libextractor", s)|}).
address@hidden deftypefun
+
address@hidden {const char *} EXTRACTOR_metatype_to_description (enum
EXTRACTOR_MetaType type)
address@hidden EXTRACTOR_metatype_to_description
address@hidden gettext
address@hidden internationalization
+
+The function @verb{|EXTRACTOR_metatype_to_description|} can be used to obtain
a longer English string @samp{s} describing the meta data type. The
description may be empty if the short description returned by
@code{EXTRACTOR_metatype_to_string} is already comprehensive. The string can
be translated into other languages using GNU gettext with the domain set to
@gnule{} (@verb{|dgettext("libextractor", s)|}).
address@hidden deftypefun
+
+
+
address@hidden Meta formats
address@hidden Meta formats
+
address@hidden enum EXTRACTOR_MetaFormat
+
address@hidden|enum EXTRACTOR_MetaFormat|} is a C enum which defines on a high
level how the extracted meta data is represented. Currently, the library uses
three formats: UTF-8 strings, C strings and binary data. A fourth value,
@code{EXTRACTOR_METAFORMAT_UNKNOWN} is defined but not used. UTF-8 strings are
0-terminated strings that have been converted to UTF-8. The format code is
@code{EXTRACTOR_METAFORMAT_UTF8}. Ideally, most text meta data will be of this
format. Some file formats fail to specify the encoding used for the text. In
this case, the text cannot be converted to UTF-8. However, the meta data is
still known to be 0-terminated and presumably human-readable. In this case,
the format code used is @code{EXTRACTOR_METAFORMAT_C_STRING}; however, this
should not be understood to mean that the encoding is the same as that used by
the C compiler. Finally, for binary data (mostly images), the format
@code{EXTRACTOR_METAFORMAT_BINARY} is used.
+
+Naturally this is not a precise description of the meta format. Plugins can
provide a more precise description (if known) by providing the respective mime
type of the meta data. For example, binary image meta data could be also
tagged as ``image/png'' and normal text would typically be tagged as
``text/plain''.
+
+
+
address@hidden Extracting
address@hidden Extracting
+
address@hidden {Function Pointer} int (*EXTRACTOR_MetaDataProcessor)(void *cls,
const char *plugin_name, enum EXTRACTOR_MetaType type, enum
EXTRACTOR_MetaFormat format, const char *data_mime_type, const char *data,
size_t data_len)
address@hidden EXTRACTOR_MetaDataProcessor
+
+Type of a function that libextractor calls for each meta data item found.
+
address@hidden @var
+
address@hidden cls
+closure (user-defined)
+
address@hidden plugin_name
+name of the plugin that produced this value; special values can be used (i.e.
'<zlib>' for zlib being used in the main libextractor library and yielding meta
data);
+
address@hidden type
+libextractor-type describing the meta data;
+
address@hidden format basic
+format information about data
+
address@hidden data_mime_type
+mime-type of data (not of the original file); can be NULL (if mime-type is not
known);
+
address@hidden data
+actual meta-data found
+
address@hidden data_len
+number of bytes in data
+
address@hidden table
+
+Return 0 to continue extracting, 1 to abort.
address@hidden deftypefn
+
+
+
address@hidden void EXTRACTOR_extract (struct EXTRACTOR_PluginList *plugins,
const char *filename, const void *data, size_t size,
EXTRACTOR_MetaDataProcessor proc, void *proc_cls)
address@hidden EXTRACTOR_extract
address@hidden reentrant
address@hidden concurrency
address@hidden threads
address@hidden thread-safety
+
+This is the main function for extracting keywords with @gnule{}. The first
argument is a plugin list which specifies the set of plugins that should be
used for extracting meta data. The @samp{filename} argument is optional and
can be used to specify the name of a file to process. If @samp{filename} is
NULL, then the @samp{data} argument must point to the in-memory data to extract
meta data from. If @samp{filename} is non-NULL, @samp{data} can be NULL. If
@samp{data} is non-null, then @samp{size} is the size of @samp{data} in bytes.
Otherwise @samp{size} should be zero. For each meta data item found, GNU
libextractor will call the @samp{proc} function, passing @samp{proc_cls} as the
first argument to @samp{proc}. The other arguments to @samp{proc} depend on
the specific meta data found.
+
address@hidden SIGBUS
address@hidden bus error
+Meta data extraction should never really fail --- at worst, @gnule{} should
not call @samp{proc} with any meta data. By design, @gnule{} should never crash
or leak memory, even given corrupt files as input. Note however, that running
@gnule{} on a corrupt file system (or incorrectly @verb{|mmap|}ed files) can
result in the operating system sending a SIGBUS (bus error) to the process.
While @gnule{} runs plugins out-of-process, it first maps the file into memory
and then attempts to decompress it. During decompression it is possible to
encounter a SIGBUS. @gnule{} will @emph{not} attempt to catch this signal and
your application is likely to crash. Note again that this should only happen
if the file @emph{system} is corrupt (not if individual files are corrupt). If
this is not acceptable, you might want to consider running @gnule{} itself also
out-of-process (as done, for example, by
@url{http://grothoff.org/christian/doodle/,doodle}).
+
address@hidden deftypefun
+
+
address@hidden Language bindings
address@hidden Language bindings
address@hidden Java
address@hidden Mono
address@hidden Perl
address@hidden Python
address@hidden PHP
address@hidden Ruby
+
address@hidden works immediately with C and C++ code. Bindings for Java, Mono,
Ruby, Perl, PHP and Python are available for download from the main @gnule{}
website. Documentation for these bindings (if available) is part of the
downloads for the respective binding. In all cases, a full installation of the
C library is required before the binding can be installed.
+
address@hidden Java
+
+Compiling the GNU libextractor Java binding follows the usual process of
+running @command{configure} and @command{make}. The result will be a
+shared C library @file{libextractor_java.so} with the native code and
+a JAR file (installed to @file{$PREFIX/share/java/libextractor.java}).
+
+A minimal example for using GNU libextractor's Java binding would look
+like this:
address@hidden
+import org.gnu.libextractor.*;
+import java.util.ArrayList;
+
+public static void main(String[] args) {
+ Extractor ex = Extractor.getDefault();
+ for (int i=0;i<args.length;i++) {
+ ArrayList keywords = ex.extract(args[i]);
+ System.out.println("Keywords for " + args[i] + ":");
+ for (int j=0;j<keywords.size();j++)
+ System.out.println(keywords.get(j));
+ }
+}
address@hidden verbatim
+
+The GNU libextractor library and the @file{libextractor_java.so} JNI binding
+have to be in the library search path for this to work. Furthermore, the
address@hidden file should be on the classpath.
+
+Note that the API does not use Java 5 style generics in order to work
+with older versions of Java.
+
address@hidden Mono
+
+his binding is undocumented at this point.
+
address@hidden Perl
+
+This binding is undocumented at this point.
+
address@hidden Python
+
+This binding is undocumented at this point.
+
address@hidden PHP
+
+This binding is undocumented at this point.
+
address@hidden Ruby
+
+This binding is undocumented at this point.
+
+
+
address@hidden Utility functions
address@hidden Utility functions
+
address@hidden reentrant
address@hidden concurrency
address@hidden threads
address@hidden thread-safety
+This chapter describes various utility functions for @gnule{} usage. All of
the functions are reentrant.
+
address@hidden
+* Utility Constants::
+* Meta data printing::
address@hidden menu
+
address@hidden Utility Constants
address@hidden Utility Constants
+
address@hidden EXTRACTOR_VERSION
+The constant @verb{|EXTRACTOR_VERSION|} is a hexadecimal
+representation of the version number of the installed libextractor
+header. The hexadecimal format is 0xAABBCCDD where AA is the major
+version (so far always 0), BB is the minor version, CC is the revision
+and DD the patch number. For example, for version 0.5.18, we would
+have AA=0, BB=5, CC=18 and DD=0. Minor releases such as 0.5.18a or
+significant changes in unreleased versions would be marked with DD=1
+or higher.
+
+
address@hidden Meta data printing
address@hidden Meta data printing
+
+
address@hidden EXTRACTOR_meta_data_print
+The @verb{|EXTRACTOR_meta_data_print|} is a simple function which prints the
meta data found with libextractor to a file. The function is mostly useful for
debugging and as an example for how to manipulate the keyword list and can be
passed as the @samp{proc} argument to @code{EXTRACTOR_extract}. The file to
print to should be passed as @samp{proc_cls} (which must be of type @code{FILE
*}), for example @code{stdout}.
+
+
+
address@hidden Existing Plugins
address@hidden Existing Plugins
+
address@hidden @bullet
address@hidden
+ARCHIVE (using libarchive)
address@hidden
+DVI
address@hidden
+EXIV2 (using libexiv2, 0.23 or later preferred)
address@hidden
+FLAC (using libFLAC)
address@hidden
+GIF (using libgif)
address@hidden
+GSTREAMER (using libgstreamer v1.0 or later)
address@hidden
+HTML (using libtidy)
address@hidden
+IT
address@hidden
+JPEG (using libjpeg v8 or later)
address@hidden
+MAN
address@hidden
+MIDI (using libsmf)
address@hidden
+MIME (using libmagic)
address@hidden
+MPEG (using libmpeg2)
address@hidden
+NSF
address@hidden
+NSFE
address@hidden
+ODF
address@hidden
+OLE2 (with libgsf)
address@hidden
+OGG (with libogg)
address@hidden
+PNG
address@hidden
+PS
address@hidden
+RIFF
address@hidden
+RPM (using librpm)
address@hidden
+S3M
address@hidden
+SID
address@hidden
+ThumbnailFFMPEG (using libavformat and related libav-libraries, including
libswscale)
address@hidden
+ThumbnailGtk (using libgtk)
address@hidden
+TIFF (with libtiff, tested with v4)
address@hidden
+WAV
address@hidden
+XM
address@hidden
+ZIP
address@hidden itemize
+
address@hidden and @file{bzip2} compressed versions of these formats are
+also supported (as well as meta data embedded by @file{gzip} itself)
+if zlib or libbz2 are available.
+
address@hidden Writing new Plugins
address@hidden Writing new Plugins
+
+Writing a new plugin for libextractor usually requires writing of or
+interfacing with an actual parser for a specific format. How this is
+can be accomplished depends on the format and cannot be specified in
+general. However, care should be taken for the code to be reentrant
+and highly fault-tolerant, especially with respect to malformed
+inputs.
+
+Plugins should start by verifying that the header of the data matches
+the specific format and immediately return if that is not the case.
+Even if the header matches the expected file format, plugins must not
+assume that the remainder of the file is well formed.
+
+The plugin library must be called libextractor_XXX.so, where XXX
+denotes the file format of the plugin. The library must export a
+method @verb{|libextractor_XXX_extract_method|}, with the following
+signature:
address@hidden
+void
+EXTRACTOR_XXX_extract_method (struct EXTRACTOR_ExtractContext *ec);
address@hidden verbatim
+
address@hidden contains various information the plugin may need for its
+execution. Most importantly, it contains functions for reading
+(``read'') and seeking (``seek'') the input data and for returning
+extracted data (``proc''). The ``config'' member can contain
+additional configuration options. ``proc'' should be called on
+each meta data item found. If ``proc'' returns non-zero,
+processing should be aborted (if possible).
+
+In order to test new plugins, the @file{extract} command can be run
+with the options ``-ni'' and ``-l XXX'' . This will run the plugin
+in-process (making it easier to debug) and without any of the other
+plugins.
+
+
address@hidden Example for a minimal extract method
+
+The following example shows how a plugin can return the mime type of
+a file.
address@hidden
address@hidden
+void
+EXTRACTOR_mymime_extract (struct EXTRACTOR_ExtractContext *ec)
+{
+ void *data;
+ ssize_t data_size,
+
+ if (-1 == (data_size = ec->read (ec->cls, &data, 4)))
+ return; /* read error */
+ if (data_size < 4)
+ return; /* file too small */
+ if (0 != memcmp (data, "\177ELF", 4))
+ return; /* not ELF */
+ if (0 != ec->proc (ec->cls,
+ "mymime",
+ EXTRACTOR_METATYPE_MIMETYPE,
+ EXTRACTOR_METAFORMAT_UTF8,
+ "text/plain",
+ "application/x-executable",
+ 1 + strlen("application/x-executable")))
+ return;
+ /* more calls to 'proc' here as needed */
+}
address@hidden verbatim
address@hidden example
+
+
address@hidden Internal utility functions
address@hidden Internal utility functions
+
+Some plugins link against the @code{libextractor_common} library which
+provides common abstractions needed by many plugins. This section
+documents this internal API for plugin developers. Note that the headers
+for this library are (intentionally) not installed: we do not consider
+this API stable and it should hence only be used by plugins that are
+build and shipped with GNU libextractor. Third-party plugins should
+not use it.
+
address@hidden defines various conversion functions for
+numbers (in particular, byte-order conversion for floating point
+numbers).
+
address@hidden defines an API for accessing compressed files.
+
address@hidden provides an interpreter for unpacking structs of integer
+numbers from streams and converting from big or little endian to host
+byte order at the same time.
+
address@hidden provides a function for character set conversion described
+below.
+
address@hidden {char *} EXTRACTOR_common_convert_to_utf8 (const char *input,
size_t len, const char *charset)
address@hidden UTF-8
address@hidden character set
address@hidden EXTRACTOR_common_convert_to_utf8
+Various @gnule{} plugins make use of the internal
address@hidden header which defines a function
+
address@hidden|EXTRACTOR_common_convert_to_utf8|} which can be used to easily
convert text from
+any character set to UTF-8. This conversion is important since the
+linked list of keywords that is returned by @gnule{} is
+expected to contain only UTF-8 strings. Naturally, proper conversion
+may not always be possible since some file formats fail to specify the
+character set. In that case, it is often better to not convert at
+all.
+
+The arguments to @verb{|EXTRACTOR_common_convert_to_utf8|} are the input
string (which
+does @emph{not} have to be zero-terminated), the length of the input
+string, and the character set (which @emph{must} be zero-terminated).
+Which character sets are supported depends on the platform, a list can
+generally be obtained using the @command{iconv -l} command. The
+return value from @verb{|EXTRACTOR_common_convert_to_utf8|} is a
zero-terminated string
+in UTF-8 format. The responsibility to free the string is with the
+caller, so storing the string in the keyword list is acceptable.
address@hidden deftypefun
+
+
+
+
+
address@hidden Reporting bugs
address@hidden Reporting bugs
+
address@hidden bug
address@hidden uses the @url{https://gnunet.org/bugs/,Mantis bugtracking
+system}. If possible, please report bugs there. You can also e-mail
+the @gnule{} mailinglist at @url{libextractor@@gnu.org}.
+
+
+
address@hidden **********************************************************
address@hidden ******************* Appendices *************************
address@hidden **********************************************************
+
address@hidden GNU Free Documentation License
address@hidden GNU Free Documentation License
+
address@hidden fdl-1.3.texi
+
+
address@hidden Concept Index
address@hidden Concept Index
+
address@hidden cp
+
address@hidden Function and Data Index
address@hidden Function and Data Index
+
address@hidden fn
+
address@hidden Type Index
address@hidden Type Index
+
address@hidden tp
+
address@hidden
Modified: Extractor-docs/WWW/run-gendocs.sh
===================================================================
--- Extractor-docs/WWW/run-gendocs.sh 2012-09-08 08:30:59 UTC (rev 23702)
+++ Extractor-docs/WWW/run-gendocs.sh 2012-09-08 08:32:35 UTC (rev 23703)
@@ -1,5 +1,5 @@
#!/bin/sh
cp ../../Extractor/doc/*.texi .
-gendocs.sh --email address@hidden extractor "GNU Libextractor manual"
+gendocs.sh --email address@hidden libextractor "GNU Libextractor manual"
man2html -r -M /s/libextractor/man/ -p ../../Extractor/doc/extract.1 | sed -e
"s/Content-type: text\/html//" > man1/extract.1.html
man2html -r -M /s/libextractor/man/ -p ../../Extractor/doc/libextractor.3 |
sed -e "s/Content-type: text\/html//" > man3/libextractor.3.html
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r23703 - Extractor/doc Extractor-docs/WWW,
gnunet <=