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.) -- / Johan Sundström, http://ecmanaut.blogspot.com/ _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
