3.1 Running fritzing as a server

Fritzing can be run as a server process by invoking the -port argument. This allows you to use it as a (remote) background service for generating conversions and exports.

There are two pathways you can use with the Fritzing server. The first pathway (PATH1) relies on a behind-the-scenes file copying operation. The idea is that you copy your set of .fzz files to be processed to some folder that is accessible to the Fritzing server, the server processes that set of files (as requested in an HTTP GET--details below), and then you copy the resulting files back to where you need them.

The second pathway (PATH2) is pure TCP/IP. Your request includes a URL to a single .fzz file to be processed. Fritzing downloads and processes the file, and if all goes well, returns a .zip file as the HTTP response.

Bullets below are labeled [PATH1] or [PATH2] if they are relevant only for a single pathway.

• Create a folder on the machine where Fritzing will be running--this folder is where input fzz files go and where output svg and gerber files are returned. Call this the exchange-folder. The exchange-folder can be anywhere that Fritzing can load a file from, it doesn't have to reside in the Fritzing folder hierarchy.

  [PATH1] Copying files to and from the exchange-folder takes place outside of Fritzing--this would be the job of a real webserver; Fritzing itself is just a back-end service for the webserver.

  [PATH2] The exchange-folder is used as the temporary storage area for files uploaded and downloaded via TCP/IP.

• Launch fritzing from the command line using the -port argument:

  .../fritzing.exe -port the-port exchange-folder [-f folder-containing-bins-parts-sketches]

  If you built Fritzing with QtCreator you will probably need the -f option to point to the folder containing parts, bins, sketches, translations, etc.

  You will see Fritzing come up normally--if the Parts Bin contains parts, then Fritzing found the parts and bins folders.

• Fritzing is now looking for tcp/ip connections on port the-port

• [PATH1] for each set of fzz files you want to serve

  • create a subfolder inside the exchange-folder (this is handled by the webserver)

  • copy the set of fzz files to the subfolder (this is handled by the webserver)

  • invoke the Fritzing server using an html GET using the port number, for example

    http://localhost:9999/"COMMANDO"/"Fzz-Folder-Subfolder"

  • available commandos are: svg or gerber

  • the Fzz-Folder is the folder-name inside your exchange folder holding the fzz's

    http://localhost:9999/svg/subfolder or http://localhost:9999/gerber/subfolder

    If you are watching fritzing at that point, you will see each fzz file opened in a separate window, processed, and closed.

  • all the fzz files in the subfolder will be processed. For the svg command, it means that the svg images for all three views are generated for each fzz input file.

  • a random .svg or drill.txt file will be returned as the html response if everything went ok

  • collect all the svg or gerber files from the subfolder and delete the subfolder (this is handled by the webserver)

• [PATH2] To process a single fzz file at URL url

  • invoke the Fritzing server using an html GET using followed by a command (svg-tcp or gerber-tcp) followed by the full URL. For example

    http://localhost:9999/svg-tcp/http://localhost:9988/files/loop.fzz

    If you are watching fritzing at that point, you will see the fzz file opened in a separate window, processed, and closed.

    The resulting svg or gerber files will be zipped up and returned in the HTTP response. If you test this from a browser, by default the downloaded file will have the same name as the file in your request (i.e. in the example above, the downloaded file would be called "loop.fzz", but it really is a .zip file containing three svgs).

If a request comes in while Fritzing is already serving another request, Fritzing will keep the later request in a queue for up to two minutes while waiting for the earlier request to finish. If the earlier request is still not done after two minutes, Fritzing will return a 503 error to the later request. This feature is not very well tested.

Note: there are a few circumstances--like problems loading a file--in which Fritzing will put up a message window and wait for a response from the GUI. I believe it is possible to root out all these cases so that the server will run standalone, but the work has yet to be done...