Christoph,
I appreciate your consideration. I'm fine with URLs being agnostic as
long as they are not completely meaningless. That is, they can function
as identifiers in some meaningful context to cross-reference actual
locations of real files or real content. Otherwise the archive is just
historical shadow, not able to regenerate.
More specifically, I'm trying to understand why the Admin server is
sending something non-meaningful to the Engage Server and the Engage
Server is treating it as meaningful. The Engage Server is the client in
this scenario. The Engage Server is refusing to be completely agnostic
about URLs in Matterhorn.
Using MH 1.4rc2, I'm trying to apply a "publish" workflow to an archive
via the Admin UI. The Matterhorn Admin server sends a partially
constructed http resource location to the Engage server. The resource
location appears to have been constructed from an Episode URN (the
Matterhorn databases episode_episode table's mediapackage). The Engage
server attempts to parse something meaningful from the location, and
cannot. So, it throws an error and freezes the workflow.
Karen
On 10/1/2012 4:11 AM, Christoph Drießen wrote:
Karen,
if hope that I understood you right so I'd like to ask if it's necessary for
you to have meaningful URLs. In general clients should be completely agnostic
about URLs in Matterhorn and should not try to extract things from it or
interpret them in a certain way.
Christoph
Am 28.09.2012 um 14:58 schrieb Karen Dolan <[email protected]>:
Christoph,
Thank you for the reply! We have been testing on 1.4rc2, so maybe things are
improved.
In MH 1.4rc2, the episode's dublin core catalogs are still dereferenced as "/0" when sent to the
Engage during publish. The dereferenced mpeg-7 file's location path does not match it's one. For instance,
the Id of the resource in path name (i.e. "catalog-4") was used in the dereferenced path but its
not part of the actual path to the resource. The correct dublin core resources path was constructed (except
for the file name) but not the mpeg-7. An mpeg-7/text flavored file generated on our system is named
"slidetext.xml". But, there is no obvious reference to that file resource in the archived version
of the mediapackage. It seems like the new scheme might reference the slidetext.xml as mpeg7.xml. I'm curious
how it could defererence that back to slidetext.xml (or maybe change the name to mpeg7.xml and put it in a
more streamlined path on archive)?
- Karen
On 9/28/2012 5:53 AM, Christoph Drießen wrote:
Hi Karen,
the "/0" is intended and describes the version of the episode in the archive.
But parts of Matterhorn -- namely the workspace -- do not like this schema without having
a file extension at the end of the URL. So as part of
fixinghttp://opencast.jira.com/browse/MH-9065 the new scheme will be something like this:
http://localhost:8080/episode/archive/mediapackage/d9c41616-f643-49e8-8b92-6d5f497eed21/track-1/1/track.mov
http://{host}/episode/archive/mediapackage/{mediaPackageId}/{mediaPackageElementId}/{version}/{type}.{fileSuffixOfMimeType}
Also the URNs you encountered in the database are correct. The episode service
acts as a long term archive so saving transient URLs does not make any sense.
That's why they are being rewritten to a location independent URN. But In fact
these URNs aren't currently used anywhere, they're just internal und should
remind the fact that this is an archived media package. If you access archived
episodes throught the episode service's REST endpoint these URNs are being
rewritten to point to the current location of the REST endpoint. By this
technique you are able to move the episode service (aka archive) to a new host
without any problem. Moving the archive to another host will likely happen in
the long run and that's something that has to be considered in terms of long
term archival.
Hope that helps,
Christoph
Am 27.09.2012 um 15:40 schrieb Karen Dolan<[email protected]>:
Does anyone else have the problem that in Episode Tab, episode details, all the URLs end
in "/0"?
Is it possible that workflows applied to an archive use the media package from
the episode_episode table? (Making all the meta-data meta-physical)
- Karen
On 9/27/2012 9:10 AM, Karen Dolan wrote:
I notice URN values in mediapackage within the episode_episode table:
<url>urn:matterhorn:c1dc4053-fdd5-4d0c-8143-d2608dfb216b:0:7213209f-6535-4d01-bf73-2fd8bf232add</url>
Normally, the url shows up as a location identifier in mediapackages. Does
anyone know if this is expected?
_______________________________________________
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]
_______________________________________________
--
Karen Dolan
Harvard University, DCE
617-998-8439
[email protected]
_______________________________________________
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]
_______________________________________________
--
Karen Dolan
Harvard University, DCE
617-998-8439
[email protected]
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
