Right now there is no feature detection, so any discussion about possible performance issues are unlaid eggs. I don't think its going to be an issue, and it also can be delayed during startup. The _rich_repr_ have the job of deciding no the best representation for a particular object, so they would naturally query for multiple different output types anyways so you wouldn't benefit that much from changing the API at that point.
The output types are intentionally rigid so you actually have to declare AND TEST them. I'm against dynamically constructing stuff that then isn't tested properly just so you can save a few keystrokes. On Monday, April 20, 2015 at 11:23:30 AM UTC-4, martin....@gmx.net wrote: > > 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.
