On 2011-09-09 5:04 AM, Pawel Fic wrote: > Hi. > > I just replaced Matterhorn 1.1. with Matterhorn 1.2 and I have noticed lots > of changes to the Rest Endpoint API. I think I also noticed some bugs. > > > To improve Matterhorn, I think is is necessary to document the Rest Endpoint > API. API Changes should also be reflected in the "Release Notes". I think > those are important - right? > > Assuming somebody improved / developed his capture agent or extension to > Matterhorn (like his custom API, custom scheduler) - it will be a huge not to > change the version from Matterhorn 1.1 to Matterhorn 1.2. > (a) you do not expect the API to change > (b) once it changes you cannot tell what changed > (c) once you design anything that supposed to work with Matterhorn, you do > not have a clue how to use the REST Endpoints properly other than guessing or > looking into the source code. > > > Does anybody from Opencast community agrees with this ? > If there any way I could get a support on this one, so once it is written > down - it will not change? So once Matterhorn will be upgraded to 1.3 all > this work will not be just wasted?
Hi Pawel, Please take a look at http://lists.opencastproject.org/pipermail/matterhorn-users/2011-September/001237.html, where Hank ran into much the same issue. G > > > ========== > Here is something I would like to start with /it's a simple example: > > My capture agent is retrieving information about scheduler recordings. > My CA Configuration is URL to Matterhorn/username and password. > URL is: http://matterhorn:8080 > > > So it gets the URL for Matterhorn and in 1.1.: > > /scheduler/my_agent/calendar > I retrieve a ICalendar file. > In Matterhorn 1.2. I think I need to change it to: > > /recordings/calendars?agentid=my_agent > And the content of ICalendar file has also changed. > > > > Other than this, I have noticed that "agentid" is not quite agent's id. > calls to: > > /recordings/calendars?agentid=my_agent > /recordings/calendars?agentid=my > /recordings/calendars?agentid=agent > > are not quite equivalent, but they all work. > So what I actually need to do right now is to: > > > (1) query for /recordings/calendars?agentid=my_agent > (2) decode binary data (attachments) > (3) see if agentid in decoded data matches my agent > (4) handle appropriate events. > > > So what I would love to have is to specify: > > 1. what is field "agentid" > 2. what is the return value of this query. > 3. what is field "seriesid" > 4. is current behavior or this endpoint bogus or proper. > > 5. a confirmation that this endpoint will not change in 1.3, 1.4, 1.5 so that > if I create a solution using Matterhorn - I will not have to rewrite 20% of > the code each time I upgrade Matterhorn. > > > =========== > Last think I do not quite understand, why the rest endpoint url's are inside > configuration files. It looks like a problem in design. > Imagine a browser with an option to configure HTML tags: > > Option HTML language: > Tag that starts the HTML page: HTML > Tag that starts a content of HTML page: BODY > Tag that starts a table: TABLE > > and people changing it.... > > Rest endpoint not supposed to change unless it is necessary, right ? > > > -Pawel > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
