openlp-core team mailing list archive

[Dave Bevan <question221503@xxxxxxxxxxxxxxxxxxxxx>]

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.