The last.fm fingerprint library
The fingerprinting process works in two steps:
1. Get PCM data and pass it to *fplib* which will return byte string to be
submitted to the last.fm HTTP fingerprint service. This will return a number
(fingerprintID).
2. Query the last.fm API with the fingerprintID and obtain the metadata in xml
format.
The lastfmfpclient directory contains an example of application that uses fplib
and queries both services.
WWW: https://github.com/lastfm/Fingerprinter
Feature safe: yes
Parse::HTTP::UserAgent implements a rules-based parser and tries to identify
MSIE, FireFox, Opera, Safari & Chrome first. It then tries to identify Mozilla,
Netscape, Robots and the rest will be tried with a generic parser. There is also
a structure dumper, useful for debugging.
User agent strings are a complete mess since there is no standard format for
them. They can be in various formats and can include more or less information
depending on the vendor's (or the user's) choice. Also, it is not dependable
since it is some arbitrary identification string. Any user agent can fake
another. So, why deal with such a useless mess? You may want to see the choice
of your visitors and can get some reliable data (even if some are fake) and
generate some nice charts out of them or just want to send an HttpOnly cookie if
the user agent seems to support it (and send a normal one if this is not the
case). However, browser sniffing for client-side coding is considered a bad
habit.
WWW: http://search.cpan.org/dist/Parse-HTTP-UserAgent/
Feature safe: yes
- Mark CVS-2009-2414 CVS-2009-2416 CVS-2011-1944 entrys as safe
- Fix whitespaces
- Bump modify date
- While here add missing blank lines between entries [1]
[1] This would not happened when committers use "make newentry" (sometimes RTFM is really helpful)
Feature safe: yes
Remove the part of files/patch-plugins__zynaddsubfx__CMakeLists.txt
which actually removed the call which linked to pthread -- it is now
needed since we do not rely on it being passed via LDFLAGS anymore.
Approved by: avilla (mentor, implicit)
Feature safe: yes
The interfaces defined here are used for file-system and
file-system-like representations of objects, such as file-system
synchronization, FTP, PUT, and WebDAV.
WWW: http://pypi.python.org/pypi/zope.filerepresentation
Submitted by: Ruslan Mahmatkhanov <cvs-src@yandex.ru> (via github)
Feature safe: yes
objects, much like MappingStorage. Unlike MappingStorage, it needs
not be packed to get rid of non-cyclic garbage and it does
rudimentary conflict resolution. This is a ripoff of Jim's Packless
bsddb3 storage.
WWW: http://pypi.python.org/pypi/tempstorage
Submitted by: Ruslan Mahmatkhanov <cvs-src@yandex.ru> (via github)
Feature safe: yes
zope.publisher allows you to publish Python objects on the web.
It has support for plain HTTP/WebDAV clients, web browsers as
well as XML-RPC and FTP clients. Input and output streams are
represented by request and response objects which allow for easy
client interaction from Python. The behaviour of the publisher
is geared towards WSGI compatibility.
WWW: http://pypi.python.org/pypi/zope.publisher
Submitted by: Ruslan Mahmatkhanov <cvs-src@yandex.ru> (via github)
Feature safe: yes
LWPx::TimedHTTP performs an HTTP request exactly the same as LWP does normally
except for the fact that it times each stage of the request and then inserts the
results as header.
It's useful for debugging where abouts in a connection slow downs are occuring.
WWW: http://search.cpan.org/dist/LWPx-TimedHTTP/
Feature safe: yes
