7.4

l MySQL
l Database can be in any location, but performance will depend on the speed of the connection between Plan-
etPress and the MySQLserver.
l MySQL's performance has been slower than SQLServer and SQLServer Express during our tests.
l By default, MySQLis configured not to allow any SQLrequest larger than 16 megs.
l In the event where 2 requests are made simultaneously on the same record, MySQLwill queue one of the
requests and execute it once the first one is done. In extremely rare cases this may cause a timeout on very
large requests.
l MSSQL(Microsoft SQLServer)
l All versions of the SQLServer are supported, including all Express versions.
l Database can be in any location, but performance will depend on the speed of the connection between Plan-
etPress Production and the SQLserver.
l In the event where 2 requests are made simultaneously on the same record, SQLServer will drop the most com-
plex request. Resubmitting the PGCfor processing should resolve this issue. This, however, should happen only
rarely.
l When configuring the ODBCconnection, your must use the Microsoft version of the driver, and not the Native
SQLversion of the driver. This is due to a technical limitation of the native driver that interferes with the Plan-
etPress Suite database requests.
Specifically for PlanetPress Capture, these considerations mean the following:
l In Microsoft Access, the total size of stored document cannot be larger than 2GB and this database will be very
unstable in implementation with more than a few thousand pattern sequences being used simultaneously. It is only sug-
gested for small implementation with less than 10 pens, or for demos.
l In MySQL, the 16 megs packet size limit can be an issue if the PDFs created by Capture are larger than this size; An
error saying "MySQLServer has gone away" would appear in this case. This can be fixed by configuring the max_
allowed_packet setting in the MySQLConfiguration(Reference).
l Also in MySQL, if a timeout occurs on simultaneous record access, resubmitting the PGCfor processing should resolve
the issue.
l In SQLServer, if one of your requests is dropped because of simultaneous accesses, resubmitting the PGCshould
resolve the issue.
Security Considerations
PlanetPress Capture introduces new and efficient methods for digitally capturing the contents of ink layed out on physical
paper. However, because of its nature, some end users may voice concerns about security and privacy. Are signatures
secure? Could their transmission be intercepted? How can the contents of the Anoto digital pen be protected from malicious
users?
Before addressing these concerns, it must be pointed out that these security issues are not introduced by this new technology.
In fact, they are essentially the same concerns that arise with plain pen and paper: if the signed document can be scanned,
then any markings on the page can be extracted and reused by anyone with even limited technical skills. In addition, the
signed document has, by definition, a longer life span than the temporary storage location of the digital pen. Consequently, it is
still the most vulnerable piece of the workflow and as such, it should be the first objective of any security effort.
In other words, as long as the physical piece of paper bearing markings is accessible to malicious users, no amount of security
protocols can protect the signed contents. It is only after the paper trail has been secured that the security and privacy issues
specific to PlanetPress Capture should be addressed.
Because PlanetPress Capture relies on external data and communication and because it may be used to process sensitive and
legal information, it is important to understand the security implications of any PlanetPress Capture implementation. Most of
Special Workflow Types