actually, there is another way to keep the exhibit api small, which is already used to handle the multiplicity of views---the script url contains arguments after its ? saying which "extensions" to the basic script should be returned as part of the script. timeline is one such "extension", I believe. So we can have as many parsers as we want, with users specifying which one will be needed for their data.
so, for much the same reason as you argue, i think it is best to have all parsers available in exhibit itself. Johan Sundström wrote: > On 12/17/06, David Karger <[EMAIL PROTECTED]> wrote: > >> Stepping in as the below-mentioned thesis advisor, I agree with you >> completely about the pluggable input stage. One of the themes behind >> exhibit is that we should not be teaching users anything, but just >> making it easier for them to do what _they_ want to do. >> > > A noble, humble and adaptive approach. Excellent. > > >> As for your concern about easier scraping, note that if exhibit has code >> to parse format X then clearly we can scrape format X too. >> > > True. (At least client side. :-) > > >> About the only concern about handling multiple formats is whether >> they can all be parsed as fast as json---obviously, it's bad if exhibit >> takes too long to load. >> > > For many cases you are likely to find in measuring load time that even > with moderate data sizes, inlining the data inside the page may in > itself prove a rather measurable speed improvement over linking to it > (via a <script> tag, or using <link> and xmlhttprequest, as presently) > as this avoids the latency of additional http requests to get at the > data. > > A bulky enough inlined format may eat up some of that time in parser > overhead, but that is yet for us to find out in profiling at a later > stage. :-) A trivial "input plugin" to write could be inline JSON, of > some form (though this defeats both graceful degradation and > separation of data and presentation -- so it's far from an elegance > sweet spot). > > >> Plus, the little issue of writing all the parsers---as david says, we're >> delighted to be helped with that. >> > > As long as there is a socket somewhere devised for the purpose of > plugging them in, and a few stubs of docs for how to integrate with > them, I'm sure early adopters such as myself will lead the way, > dropping in input converters for whatever formats they need to be able > to read runtime. > > The currently suggested method of using Babel to convert input > before-hand is wise for many reasons in the case of static data, most > importantly to be able to keep down the load size of the Exhibit API > itself to a minimum, rather than cram a heavy-weight catch-all parser > library in there. For multi-server multi-tier applications of Exhibit, > though, we'll need a JSON schema translator system, though. > > Fortunately, due to the harsh limitations of the javascript security > model, JSONP is about the only input format we are likely to encounter > for this use case, as normal unprivileged javascript (such as Exhibit) > can not read text, HTML or XML off of other servers due to the same > domain policy. > > So, in conclusion, I think we'll mostly see JSON transformations of > various kinds to fill this gap. I personally believe other format > converters ought to go into Babel, for best effect. (Not including > present stubs, which fit nicely into the picture primarily for > graceful degradation rather than input format conversion.) > > _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
