Ruben, > What it is absurd is that we can modify a series ACL using the > series-service, but the service itself does not go through all the videos in > that series (which nobody but the service knows) and modify things > accordingly (in assets which are internal to that very service). > > I understand and praise the advantages of the workflow approach, but things > like this show that it's completely conter-productive to apply it in each and > every situation where a recording (metadata) is modified.
I am not sure that "absurd" is the correct term. You are looking at two different services in a service-oriented architecture, which means that in theory each service can be used standalone. This in turn means that you shouldn't apply wiring in between the services because that introduces dependencies that ties the services into a specific application infrastructure. So far for the theoretical approach. In real life, you need to carefully consider which applications make up your lecture capture application and which ones are meant to remain reusable components. Although still kind of bad, it's probably ok to wire the lecture capture components as needed. The second issue is that you seem to be making assumptions about a certain use case. You may want to update the already distributed episodes, but you may as well not and apply the new setings for upcoming recordings only. In addition, you probably want to update your distribution channels as well as the Matterhorn archive, and before you know it, your series service now has dependencies on all the other services. Possible approaches to solving this problems are a) Event/message queue (search service and others are listening for series changes) b) Service-to-service calls (series service calls search and others) >From my point of view, a is the better solution in this case. But it also >introduces the risk of establishing parallel infrastructures (eventing as >compared to the workflows) and we need to make sure we are not putting up even >more rope for users to hang themselves. Tobias _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
