KDE 3.5 API Reference kviewshell
DjVuMemoryPort Class Reference
Memory based port. More...
#include <DjVuPort.h>
Public Member Functions | |
| void | add_data (const GURL &url, const GP< DataPool > &pool) |
| virtual GP< DataPool > | request_data (const DjVuPort *source, const GURL &url) |
DjVuPort.h | |
Files #"DjVuPort.h"# and #"DjVuPort.cpp"# implement a communication mechanism between different parties involved in decoding DjVu files. It should be pretty clear that the creator of {DjVuDocument} and {DjVuFile} would like to receive some information about the progress of decoding, errors occurred, etc. It may also want to provide source data for decoders (like it's done in the plugin where the real data is downloaded from the net and is fed into DjVu decoders). Normally this functionality is implemented by means of callbacks which are run when a given condition comes true. Unfortunately it's not quite easy to implement this strategy in our case. The reason is that there may be more than one "client" working with the same document, and the document should send the information to each of the clients. This could be done by means of callback {lists}, of course, but we want to achieve more bulletproof results: we want to be sure that the client that we're about to contact is still alive, and is not being destroyed by another thread. Besides, we are going to call these "callbacks" from many places, from many different classes. Maintaining multi-thread safe callback lists is very difficult. Finally, we want to provide some default implementation of these "callbacks" in the library, which should attempt to process the requests themselves if they can, and contact the client only if they're unable to do it (like in the case of {DjVuPort::request_data}() with local URL where {DjVuDocument} can get the data from the hard drive itself not disturbing the document's creator. Two classes implement a general communication mechanism: {DjVuPort} and {DjVuPortcaster}. Any sender and recipient of requests should be a subclass of {DjVuPort}. {DjVuPortcaster} maintains a map of routes between {DjVuPort}s, which should be configured by somebody else. Whenever a port wants to send a request, it calls the corresponding function of {DjVuPortcaster}, and the portcaster relays the request to all the destinations that it sees in the internal map. The {DjVuPortcaster} is responsible for keeping the map up to date by getting rid of destinations that have been destroyed. Map updates are performed from a single place and are serialized by a global monitor. DjVu decoder communication mechanism.
| |
| virtual bool | inherits (const GUTF8String &class_name) const |
Detailed Description
Memory based port.This {DjVuPort} maintains a map associating pseudo urls with data segments. It processes the request_data# notifications according to this map. After initializing the port, you should add as many pairs #<url, pool># as needed need and add a route from a {DjVuDocument} or {DjVuFile} to this port.
Definition at line 301 of file DjVuPort.h.
Member Function Documentation
Adds #<url, pool># pair to the internal map.
From now on, if somebody asks for data corresponding to the url#, it will be returning the pool#
Definition at line 697 of file DjVuPort.cpp.
| bool DjVuMemoryPort::inherits | ( | const GUTF8String & | class_name | ) | const [inline, virtual] |
Returns 1 if class_name# is #"DjVuPort"# or #"DjVuMemoryPort"#.
Reimplemented from DjVuPort.
Definition at line 503 of file DjVuPort.h.
If url# is one of those, that have been added before by means of {add_data}() function, it will return the associated {DataPool}.
ZERO# otherwize.
Reimplemented from DjVuPort.
Definition at line 686 of file DjVuPort.cpp.
The documentation for this class was generated from the following files:
