Hi! In http://trac.sagemath.org/ticket/7298 (on HTML5 <video> for animations) and some other tickets I'm currently dealing with the effects of the rich output framework introduced by Volker in http://trac.sagemath.org/ticket/17234. I've some concerns about the scalability of this approach, and would like your opinion on whether the following changes would make sense (so I'd create tickets for them).
Currently, the list of formats supported by a backend is fixed. But in the long run, it might make sense to perform some auto-detection there, absed on what browser the notebook is running on, or what software the user has installed on their system, or whatever. Such computation could take a bit of time. Hopefully not much for each individual check, but it adds up. So I'd propose to change from a single list of all supported formats to an API where content creators can query for distinct formats. So you'd no longer ask the backend for all its supported formats, and then check whether a format you like is in that list, but directly ask the backend whether it supports a given format. The result of that query could be more than a single yes/no answer. It could come with a quality measure, the way the HTTP Accept header works. That quality could be used to distinguish between formats which can be reproduced well and formats which will give poorer results. It could also be used to distinguish between formats whose support is absolutely certain and formats where support is assumed but still depends on a number of factors which are difficult to check for, like e.g. support for a given codec within a supported video container format. Perhaps it's not a wise choice to identify output container types with output format identifiers. As it is, whenever I want to support an additional format, I have to create a new type. Statically this can lead to a lot of redundant code, since every type is supposed to come with a docstring and examples and whatnot, even though all of that except for the format name will probably copied and pasted from some other format. Things get even if someone at some point decides to create additional format identifiers at runtime. So far that would entail some dynamic type construction, which feels a bit like Voodoo, and might make this approach scarier than it has to be. So perhaps we should have one class (plus perhaps some subclasses) representing formats, and another class (again with subclasses) representing content. The content object could then contain a reference to the format for which it was created. These ideas obviously build on one another. Do you think they are worth pursuing? Right now there is no urgent need for any of this, but that might change in the long run, and the sooner we change the API, the less code we break in the process. Since the current API got released in Sage 6.6, I guess we'd have to follow deprecation procedures in any case, but I believe that it should be feasible to provide backwards-compatible transitions for all of the above. Greetings, Martin von Gagern -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
