I agree with Stephen, this technically is a change in api but so subtile, that it should be able to get in anyways. I am not aware of any CA implementation that would refuse to process the scheduling data because the content type is different from text/plain.
Maybe the CA vendors want to chime in? Tobias On 17.10.2012, at 08:53, Stephen Marquard <[email protected]> wrote: > I wouldn't really regard a change in the Content-Type header as an API > change. Content-Type is really a hint to the consumer (client) about how to > process the content. > > In this case it's just a more accurate description of what the content really > is. But I also think it's largely cosmetic and is not responsible for the > actual functionality problems which are the result of the incorrect > implementation of IoSupport.readFileFromURL() described in MH-9184. > > Regards > Stephen > > Stephen Marquard, Learning Technologies Co-ordinator > Centre for Educational Technology, University of Cape Town > http://www.cet.uct.ac.za > Email/IM/XMPP: [email protected] > Phone: +27-21-650-5037 Cell: +27-83-500-5290 > > >>>> Rubén Pérez<[email protected]> 10/17/2012 2:14 AM >>> > What I would do is trying to keep compatibility for a release or two (that > can be years :D) and then remove the old Content-Type completely. > > JAX-RS allows for the @Produces annotation to specify several possible > content-types, and it even has a mechanism for negotiating such types (or > so I read here: > [1]<http://java.net/projects/jersey/lists/users/archive/2009-10/message/475> > ). > > Rubén Pérez > TELTEK Video Research > www.teltek.es > > [1]<http://java.net/projects/jersey/lists/users/archive/2009-10/message/475> > http://java.net/projects/jersey/lists/users/archive/2009-10/message/475 > > 2012/10/17 Greg Logan <[email protected]> > >> Hi folks, >> >> We appear to have a small cluster of issues (MH-8767, MH-9184, MH-9219, >> MH-9228) which all relate to the calendaring, the CA, and Unicode. The >> question I present to you here is what happens when fixing a bug changes >> the REST API? The fix for MH-9219 is simple and, in my opinion, low >> risk, but it does change the REST API for the calendar subsystem. Can >> we apply this to 1.4, or does it need to wait for 1.5? >> >> I think it should go in, but I know there have been some very strong >> feelings with regard to changing APIs. In this case, the API change >> merely changes the mimetype from plain text to calendaring data. >> >> Thoughts? >> >> G >> >> >> _______________________________________________ >> Matterhorn mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected] >> _______________________________________________ > > > > > ### > > UNIVERSITY OF CAPE TOWN > > This e-mail is subject to the UCT ICT policies and e-mail disclaimer > published on our website at > http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 > 21 650 9111. This e-mail is intended only for the person(s) to whom it is > addressed. If the e-mail has reached you in error, please notify the author. > If you are not the intended recipient of the e-mail you may not use, > disclose, copy, redirect or print the content. If this e-mail is not related > to the business of UCT it is sent by the sender in the sender's individual > capacity. > > ### > > > _______________________________________________ > 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] _______________________________________________
