Is there a page describing the OSZ file format?

Sorry no.
The osz file is a zip file containing the media files and a osd file.
The osd file is a python pickle of service item arrays.
If php is able to read/write python pickles then this is would be possible.

Thanks for the hint.

I've written two simple osd2json and json2osd scripts which expose the data. For example:

#!/usr/bin/python
import sys, cPickle
try:
 import json
except:
 import simplejson as json
print json.dumps(cPickle.loads(sys.stdin.read()));

Is there any chance, for future interoperability and more openness, that OpenLP could switch to JSON encoding for .osz file writes (perhaps JSON->.osj?), whilst supporting .osd->PICKLE and .osj->JSON->PICKLE for reads?

My project involves the following work around OpenLP:

We have, for many many years, run our own online service planning website (PCS), featuring a searchable database of all the song lyrics from our previous in-house projection application (1000+ songs) - we call this our "BO" period..."Before OpenLP"!

This enabled service planners to build a running order, preview lyrics, had an interface to biblegateway.com for readings, managed our CCLI activity records, etc, etc - all the good things large worship teams need to survive. It interfaced with our volunteer planning/scheduling system (http://www.onlinerotas.com/fbc - a site written by one of our worship leads who works for Oracle), importing shell running orders from the service planner grid on that system.

Phase 1 of a re-work on PCS was completed recently - migrating the OpenLP machine to use MySQL - the same database server hosting our service planning system. Also in P1 was a switch from our previous songs database, to share the same OpenLP database now present on that server. So our teams can search and plan using the same content our OpenLP projection team use. PCS also features song addition and lyric editing - now working against the OpenLP database, creating OpenLP-compliant content. So worship leaders adding new content during the week automatically provide it for the OpenLP team (which that REALLY like!)

Phase 2 is the export of prepared running orders (songs & readings) from PCS to a network share - hence the question re the file format. So, thanks to your hint Tim, I can now write OSD files, and therefore OSZ files, which closes the loop between planning and execution (which the OpenLP team also like!).

A further thought re interfaces. Is the code structured internally such that the songs search/list/get_lyrics/set_lyrics interfaces are abstracted from any underlying database queries? Obviously there's already a layer of abstraction between songs and sqlite/mysql - but is there a higher level one too?

I ask because, besides services held in our building - i.e. on our LAN - we also run at outside venues. I'd like to explore the possibility of adding a secure, authenticated, web services interface such that search/list/get_lyrics/set_lyrics can be actioned over that web layer (hosted on our PCS site), thus enabling our remote users to participate with minimal upheaval/complexity. Yes, I've seen various posts about keeping sqlite files in sync, but it's not really a proper network-aware solution - if I'm honest, it all feels rather hacky. Supporting a properly-defined WS interface could solve all those problems. Of course, one would need the ability to host a server at the middle, but for organisations so inclined, that shouldn't present too much of a problem.

Thoughts on any of the above?

Regarding the service files, there is an open wishlist item to make a more portable service file, however as with many things it just requires someone with the time to progress it! https://bugs.launchpad.net/openlp/+bug/903773