If no vendor is concerned about the content-type change, then I'm OK with doing the change directly. However, I'd like to stress the fact that changes, no matter how subtle they are, may lead to big issues. The content-type, as "cosmetic" as it may seem, prevented us from pseudo-streaming videos correctly from nginx because it was not correctly specified in downloaded files, for instance. I just want to make sure that we don't break a lot changing a little.
Speaking on Teltek's behalf, we don't have any problems with the Content-Type change as far as I know. Rubén Pérez TELTEK Video Research www.teltek.es 2012/10/17 Tobias Wunden <[email protected]> > 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] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
