Question #221503 on OpenLP changed: https://answers.launchpad.net/openlp/+question/221503
Dave Bevan posted a new comment: 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? -- You received this question notification because you are a member of OpenLP Core, which is an answer contact for OpenLP. _______________________________________________ Mailing list: https://launchpad.net/~openlp-core Post to : openlp-core@lists.launchpad.net Unsubscribe : https://launchpad.net/~openlp-core More help : https://help.launchpad.net/ListHelp