> >> Why not use RESTful urls, rather than query string parameters? Will the >> h264.code-shop software handle that? > > The pseudostreaming takes a similar approach as the w3c media fragments spec > -- http://www.w3.org/TR/2009/WD-media-frags-20091217/ -- which recommends > either URI queries (which many media players implement) or URI fragments, > both of which are probably appropriate (and better semantically?) in this > application. > > Chris
Hi Chris. I think this is similar to the way that people have run Fedora over, for example, Djatoka: Mapping the service calls to OpenURL URIs, etc. But there's also some limitations in what data are available for URL substitution (and the larger limitation of http bindings and url substitutions themselves). I can imagine that being able to substitute some value from the DC stream, or the object of a triple in RELS-EXT, might make things better suited to this kind of service proxying. As it stands, if the service you want to call isn't able to make sense of a PID or call back to Fedora for the data via a datastream URI, you're often stuck implementing intermediary wrappers. Are these the kind of difficulties keeping you from going the disseminator route? I think there's some ongoing conversation in the community about the way services work, and it's be great to get your input. To get back to your philosophical question: Ideally (if I may), this is the kind of thing that should happen through defined services. Datastreams are intended to be a specific addressable resource (so that, for example, checksumming is supported and understood to be relevant to the resolved bytes). regards, Ben ps: Cool stuff over there at WGBH! ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
