Oops! My bad! I was including the "/doc" part in the URL :S How is it that you get the xml schema of the returned entity? Does it work with all services?
2011/9/14 Josh Holtzman <[email protected]> > That's because the workflow service isn't running on that machine. I chose > another service, at random, the "annotation" service: > > http://opencastbasecamp.media.uvigo.es/annotation/?_wadl&_type=xml > > Josh > > On Sep 14, 2011, at 7:41 AM, Rubén Pérez wrote: > > 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] > _______________________________________________ > > > > _______________________________________________ > 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] _______________________________________________
