Re: [libextractor] getting metadata from a buffer instead of a file?

[Christian Grothoff]

Hi!

Well, if that _were_ possible, we would have done that in the first place
(instead of the filename).  However, some plugins depend on 3rd party libraries
which _only_ support the filename approach.  In order to enable
these kinds of plugins, we decided to require a filename (which LE internally
mmaps to make it easy and efficient for plugins to access the data from a
buffer).  Again, I am aware that a buffer-only API would be a nice thing to
have, and if we ever manage to get all of our dependencies to the point that we
can just operate on buffers, this API will be extended in that way.

As a workaround, I believe writing the file to /tmp and then calling LE should
be an acceptable option for most apps.  If that is not possible for your app, I
would welcome any help in converting all LE plugins to buffer-only code (in
particular, talk to the authors of xpdf and exiv2 (I suspect exiv2 will be easy
and xpdf near-impossible, but I maybe wrong).  I can fix thumbnails myself
easily and probably figure a way to do zlib (gz) files in memory
(man-extractor).  That should be it (according to a quick look over the current
code).

Happy hacking :-)

Christian

Quoting Sergey 'Jin' Bostandzhyan <address@hidden>:
> Hi,
>
> first of all - thanks for the cool library :) We are writing a UPnP
> mediaserver and we will be using libextractor in our project.
>
> One question:
> I encountered a situation where I have some content that I would like to
> analyse with libextractor in a buffer and not in a file. Is it correct,
> that with the current libextractor API it is only possible to pass a filename
> to the library?
>
> Could you by chance add a function similar to EXTRACTOR_getKeywords, which
> would process a buffer instead of a file? :)
>
> Thanks,
> Sergey
>
>
>
> _______________________________________________
> libextractor mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/libextractor
>