Hi Tobias, Comments inline
Best regards 2011/11/8 Tobias Wunden <[email protected]> > 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. Perhaps I've been too harsh in this. I tend to be so much passionate with my opinions and that's not always good. Sorry about it. > 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. > Perhaps it's a matter of defining use cases. Since a user can not apply specific access permissions to single recordings (AFAIK), but they can apply those to series, one would expect that the videos contained in a series inherit its access permissions. A series which I have access to, containing videos I *don't* have access to, does not seem like very useful to me. Specially when a user can *not* define access rights to single videos. One more thought, does not applying an ACL on ingestion tie the services into a specific application infrastructure either? It's not rethorical, I really cannot see the difference and I would like to know your vision on this. > 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. > I think it's fair enough to make the assumption that the videos in a series inherit its access rights. Having different ACLs within the same series renders the whole series ACL unnecessary and impractical (if the videos within a series have different ACL, what's the point of a general ACL after all?). 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. And what if the episode service triggers one workflow to apply a certain series/acl to an episode/group of episodes (maybe all the episodes in a series?). I believe this would not mean so much extra work and would fit in the whole "workflow" model we have been following.
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
