Sorry, it isn't. But you can check this one: http://opencastbasecamp.media.uvigo.es , which neither works...
2011/9/14 Josh Holtzman <[email protected]> > WADL has been provided for each endpoint since the earliest Matterhorn > prototypes. What is the server's URL? Is it publicly accessible? > > Josh > > On Sep 14, 2011, at 7:31 AM, Rubén Pérez wrote: > > For example, WADL for the human readable docs at > http://[matterhornserver]/workflow/docs there is a WADL at >> http://[matterhorn server]/workflow/?_wadl&_type=xml > > > I'm sorry, Josh, but that does not work for me in a Matterhorn 1.2... > > 2011/9/14 Josh Holtzman <[email protected]> > >> The docs are the human-readable format of the REST API. They were >> designed to help developers quickly and easily integrate. It sounds like >> you want a more formal description of these services, which we povide in the >> form of Web Application Description Language (WADL): >> >> http://en.wikipedia.org/wiki/Web_Application_Description_Language >> >> For example, WADL for the human readable docs at >> http://[matterhornserver]/workflow/docs there is a WADL at >> http://[matterhorn server]/workflow/?_wadl&_type=xml >> >> In the docs, search for the phrase "Returned entity schema" and click the >> link next to it: this provides the XML schema of the object returned by >> this endpoint. >> >> I understand that coming into the project at this point can be difficult. >> But you should not have to read through the code to integrate with >> Matterhorn's REST endpoints. If the endpoints are not properly documented, >> or are confusing, please file bugs and if possible, suggest language to make >> them clearer. >> >> That said, if you're interested in putting together diagrams and other >> forms of documentation, I'm sure that would be appreciated! >> >> Josh >> >> On Sep 13, 2011, at 11:05 AM, Pawel Fic wrote: >> >> > Hi, >> > >> > How about creating [or publishing] on Matterhorns Wiki UML Diagrams for >> Matterhorn and some additional spec. >> > >> > You know, it you are familiar with Matterhorn everything may be very >> simple. If you are new to Matterhorn - hours of reading the source code may >> lead you to a conclusion: it chaos. >> > >> > Spec and documentation will help to maintain the project. >> > >> > I think good start would be System context diagram and Data flow diagram >> (to understand Matterhorn): >> > http://en.wikipedia.org/wiki/System_context_diagram >> > http://en.wikipedia.org/wiki/Data_flow_diagram >> > >> > But of course -- to do it right we may start from the beginning (like >> Use cases). >> > http://en.wikipedia.org/wiki/Use_case_diagram >> > >> > >> > >> > >> > and [I need] spec for REST endpoint that are responsible for integrating >> capture agent with Matterhorn: >> > 1. Capture Agent Admin REST Endpoint >> > 2. Ingest REST Endpoint >> > 3. Scheduler REST Endpoint >> > >> > Current spec (Docs) are not sufficient. Since it is generated >> automatically it is exposed to rapid changes. Engineer changes "calendar" to >> "recordings" and capture agents all over the world needs to be updated. >> > I don't mind if the change was necessary, but if this was only a >> cosmetic change. Because it looked better. >> > With new approach (spec on Matterhorn's Wiki) engineer will have to >> update the spec on Wiki first and he will be aware that this change affects >> other parts of the system. >> > >> > Other than this - docs are not sufficient. And then they cannot be used >> by third party software. Also engineers who are new to the project, may not >> understand why: /capture-admin/recordings provides them with empty list >> instead a list of recordings just like the spec says [Return all registered >> recordings and their state]. >> > >> > >> > do you think this is a good idea ? >> > >> > what are your thought on use cases / data flow diagrams ? >> > >> > what are your thought on spec of crucial endpoints. >> > >> > >> > --the benefits would be that we would know what the code is actually >> doing. Right now, I think only the people who wrote a particular piece of >> code actually are aware how it supposed to behave. >> > >> > -Pawel >> > >> > >> > >> > _______________________________________________ >> > 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 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 mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
