Hi Judy et. al.,
Currently Entwine is focused on customer work and the 1.4 release prior to 
demo'ing any new code. Rest assured we will schedule time to show off the new 
features and take community feedback prior to committing.  If anyone has 
"spare" cycles, please squash a few bugs so we can roll this out sooner. 

Thanks for the support, 
Andy


*************
Andy Wasklewicz
CEO, Co-Founder
[email protected]
mobile: 1 408 242 5630

Entwine - Knowledge In Motion 
www.entwinemedia.com
@entwinemedia on Twitter 



On Sep 14, 2012, at 9:35 AM, Judy Stern <[email protected]> wrote:

> Great to hear, Tobias!
> Any chance of doing some kind of demo/community design review? Sooner rather 
> than later? (i.e. so that the community can get a fuller understanding of 
> your plans, as well as perhaps provide feedback.)
> 
> grateful for Entwine's work,
> Judy
> 
> On Sep 14, 2012, at 4:58 AM, Tobias Wunden wrote:
> 
>> Hi Judy et al,
>> 
>> I apologize to be late to the deferred publishing party. At least I am 
>> hoping to bring good news, since I am happy to tell you that the feature 
>> under discussion is currently being developed for a customer of ours and 
>> there is agreement on pushing this feature back to the community as soon as 
>> 1.4 is out the door.
>> 
>> The approach is based on ACLs, which means that the system will do the usual 
>> processing (including option hold operations) but may publish to Engage with 
>> an ACL that prevents viewing by certain groups of people (i. e students). 
>> Once the publishing date is there, the ACLs of the recordings get updated 
>> which may result in these groups now being able to view the recording. In 
>> addition, with every change in ACL a workflow can optionally be executed so 
>> you could for example push/rectract the recordings to external distribution 
>> channels at the time of updating the ACL in Engage.
>> 
>> The ACLs can both the adjusted on a per series as well as on a per recording 
>> basis, so we can take full series online/offline as well as single 
>> recordings. With a little bit of code, individual behavior like releasing 
>> after 2 days of ingest or recording can be achieved.
>> 
>> I will add more information as soon as we are getting to a point where the 
>> code is ready to be moved in, which again will be past the 1.4 release.
>> 
>> Tobias
>> 
>> 
>> On 12.09.2012, at 01:50, Judy Stern <[email protected]> wrote:
>> 
>>> Here at UC Berkeley, our existing webcast administration system has a 
>>> publish delay feature, where he can specify that recordings for a course 
>>> not be made available for a specified number of hours or days. This is 
>>> appreciated by instructors who feel that immediate publication of their 
>>> lectures encourages student absences from class. (One instructor, who opted 
>>> for a several day delay,  wrote: "a number of my colleagues in CS have been 
>>> hesitant to have webcasting because they believe students won't come to 
>>> class anymore, but so far my experience is that this short delay is enough 
>>> to prevent that problem".)
>>> 
>>> The relevant user story, http://opencast.jira.com/browse/MH-5393, is now 
>>> assigned to Michelle, who is project managing our local efforts. Our UI 
>>> work will likely involve minor changes (an extra element or two) on the 
>>> Scheduling/Upload UI's; we also need to decide where such "delayed" 
>>> recordings appear in the Recordings tab. John King, one of our developers, 
>>> will also likely be writing new workflows and workflow operations to enable 
>>> this.
>>> 
>>> I would like to hear from any of you if your institution would be 
>>> interested in using this feature, or if you would like to participate in a 
>>> community design review of this feature. (We think it's good open source 
>>> citizenship to share with the community what we're working on, and would 
>>> love to take into account the needs of other institutions wherever 
>>> possible.) If there's interest in a design review meeting, I'll work with 
>>> those interested to schedule. 
>>> 
>>> Regards,
>>> Judy Stern
>>> 
>>> 
>>> _______________________________________________
>>> Matterhorn mailing list
>>> [email protected]
>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn
>>> 
>>> 
>>> To unsubscribe please email
>>> [email protected]
>>> _______________________________________________
>> 
>> _______________________________________________
>> Matterhorn mailing list
>> [email protected]
>> http://lists.opencastproject.org/mailman/listinfo/matterhorn
>> 
>> 
>> To unsubscribe please email
>> [email protected]
>> _______________________________________________
> 
> _______________________________________________
> Matterhorn-users mailing list
> [email protected]
> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users

_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn


To unsubscribe please email
[email protected]
_______________________________________________

Reply via email to