RTTSoftware Support Forum

PDF Explorer => General => Topic started by: dirkdekker on August 14, 2009, 11:54:51 AM

Title: embedded HTML server
Post by: dirkdekker on August 14, 2009, 11:54:51 AM
To use PDFExplorer and embedded HTML server on a Windows server, a service installer is necessairely.
Is the software delivered with a service installer?
Title: Re: embedded HTML server
Post by: RTT on August 14, 2009, 04:17:06 PM
No such functionality provided but, you can always:

Create a User-Defined Service

In new Windows Server editions, use the task scheduler

Use third party tools that are able to run applications as a service
Title: Re: embedded HTML server
Post by: RTT on October 26, 2009, 11:02:43 PM
Done. From v1.5 build 59, it will be possible to run the embedded web server, that provide the PDFE web interface functionality, and the folders monitor automatic indexer feature, as a Windows service. A GUI service installer, and uninstaller functionality, is provided to facilitate respective tasks.
This way it will be possible to start the PDFE web interface, and keep it running, even without the need to have a Windows user logged in.
Title: Re: embedded HTML server
Post by: ujd100 on November 01, 2009, 02:23:47 PM
Am inches away from recommending PDFExplorer (1 site or 5 site) license to my company for managing a shared drive folder filled with PDFs as the "eTechnical Library".   All functionality in the latest version seems to work great.  However, with the embedded HTML server, would there be a way for employees to search the database by KEYWORD or TITLE, etc specifically??  It appears the current version searches all fields at the same time. Am I correct?

This software is an ideal fit otherwise.


Urban De Souza, Ph.D.
Senior Materials Engineer/Scientist
Title: Re: embedded HTML server
Post by: RTT on November 01, 2009, 04:28:14 PM
Yes, you are correct. There is no way, yet, to specify in what fields to search for. This will eventually change in future versions, but this initial decision resulted from the fact it's not usual, if metadata fields are filled in a logical and organized way, to have same information in different metadata fields.

And now, a glimpse of the next PDFE version, web interface API possibilities. This little API enable the creation of completely customizable web interface clients.
Attached, a screenshot of a web interface client, in this case an html/javascript based one (using the excellent ExtJS library), running as a stand alone desktop application with the help of the Google Prism for Firefox plugin.
With all this power in the client side, metadata fields filter is a easy to develop feature :)
Title: Re: embedded HTML server
Post by: ujd100 on November 01, 2009, 08:08:57 PM
Good to know future versions will have client side power and additional functionality for technical/scientific library searching.   

I had another question though unrelated to the HTML server - so feel free to suggest an alternate forum:   If two separate databases are created by pointing to two different folder destinations on the corporate file systems, how does one merge them together into a single database retaining all the latest metadata edits that have been made one both to that point.  Merging would also mean moving both PDF repositories into one on the file system and maintaining one database for centralization.   This capability would help centralization efforts when multiple employees maintain their own stashes of PDFs and use PDFExplorer to build metadata information seperately.

thanks for any tips on this.

Sr. Materials Engineer/Scientist.

Title: Re: embedded HTML server
Post by: RTT on November 01, 2009, 09:36:22 PM
When metadata is edited, these changes are committed to the PDFE database, but also to the PDF file itself. This don't happen only when edited PDFs are present in a read-only media, i.e. CD/DVD-ROM, etc., in which case only database gets the changes. In all other cases, the database is manly used to speed up operations. Gathering metadata from files is a relative slow process.

So, you realy don't need to merge databases. Just move the PDFs repositories to the central location, and index these new files with the central PDFE instance. Edited metadata will show up.
Title: Re: embedded HTML server
Post by: ujd100 on November 02, 2009, 02:08:29 PM
What changes with the file on a shared network drive when meta-data is added and database updated?  Is the meta-data tagged to the filename or to some other unique identifier with the file. I believe that uniqueness is needed to distinguish between same name files, for example, that were moved to the same foldler location on the network in an effort to centralize repositories.

Title: Re: embedded HTML server
Post by: RTT on November 02, 2009, 07:08:23 PM
You can't have two files with same name in same folder, so I don't understand your doubt here!!
If you later move the files to the central repository, files names must be unique, or you are going to overwrite the ones already there.
In the PDFE database, metadata is linked to the full path+filename, this full path+filename is what's used as uniqueness identifier, exactly what happens with the file system.
Or you have not understood my last post, or I'm missing what you really want to accomplish, and/or the method you what to use.
What's usually done with PDFE is to have all the files in a central files server. LAN PCs can concurrently edit these PDFs metadata across the network, maintaining a local database, but because metadata is also committed to the PDF files itself, the main PDF Explorer instance, the one serving the web interface, only has to maintain the index actualized.
Title: Re: embedded HTML server
Post by: ujd100 on November 12, 2009, 02:29:17 PM
Sorry for not being clear.  In our environment (2-3 R&D engineers), the same source PDF file may be named differently by two different engineers in two separate folders in the central repository.  I think you've answered my question - i.e. there is no way to eliminate the duplicate PDF unless one of the files is manually removed via PDF Explorer or otherwise.