> On May 14, 2019, at 2:48 PM, Fred Gleason <[email protected]> wrote: > > On Tue, 2019-05-14 at 13:53 -0700, Patrick Linstruth wrote: >> It is the scheduler that has a very specific methodology based on >> importing a flat file at the time the person wants to do the merge. >> The mere presence of a file turns the red lights green that data is >> available for a merge. The concept of the "live log" updates you >> mentioned doesn't seem to fit the existing architecture. > > If 'live log' type operations are off the table, then it should fit > pretty neatly into the existing framework. We need one new enumeration; > call it 'schedule source'. It can have two possible values: 'Column > Aligned File' (the existing implementation) and 'MusicMaster Nexus'. In > each case, the goal is to transform a schedule from the given > representation to a set of rows in the 'IMPORTER_LINES' table. Once > that's done, the rest of the log merge can proceed just as it does now. >
The library could be live in both directions as I believe the existing framework will support that with minimal changes. I'll have a better opinion on the scheduler later. > >> At this point I'm leaning towards an rdnexusd daemon and a separate >> admin/configuration from Replication to handle external schedulers. > > Assuming that the Nexus architecture permits it, I think I'd treat the > audio replication and the schedule integration as entirely orthogonal > processes. Audio replication properly belongs in rdrepld(8) with > configuration in RDAdmin->ManageReplicators, while schedule importation > should be configured in RDAdmin->ManageServices. As for the implementation > thereof, it depends. Is Nexus built around a 'push' or a 'pull' model? Which > side initiates schedule transfers? It's a pull model. The client (Rivendell) initiates all transfers. I feel that ManageServices is where the MusicMaster stuff should go. The library is pretty slick. We can ask for a list of song/metadata changes since the last time we asked. The scheduling isn't quite as elegant. We can either ask for a date/time range and get elements (log events) or not, or there is a "last scheduled" date we can poll for and request new elements that way. Both of these are only a problem if more than one Rivendell host is asking for the same information, in which case we'd have to manage syncs another way. > > Cheers! > > > |---------------------------------------------------------------------| > | Frederick F. Gleason, Jr. | Chief Developer | > | | Paravel Systems | > |---------------------------------------------------------------------| > | Handshaking protocol, n: | > | A process employed by hostile hardware devices to initiate a terse | > | but civil dialogue, which, in turn, is characterized by occasional | > | misunderstanding, sulking and name-calling. | > |---------------------------------------------------------------------| > _______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
