Nick, Larry, I would like to go over the SimileAjax + jQuery issue that you brought up. When I started Timeline in mid 2006, it wasn't clear which of the 30+ ajax libraries, including jQuery, dojo, prototype, mootool, etc., would become the dominant one. For that reason I created SimileAjax from scratch so that Timeline could be integrated into any system with few conflicts. I also intended for much of SimileAjax to be replaced with the dominant ajax library in the future, which from opinions of those near me in summer 2007, turned out to be jQuery.
That said, there are a lot of functionalities in SimileAjax that are still not in jQuery proper: - the ability to get a callback invoked after loading several Javascript files. This is very important for integrating Timeline, Timeplot, and presumably future widgets into Exhibit. - generating HTML for translucent PNGs that work on IE6. - generating anchored automatically-sized popups. - performing string substitution for localizing UI text. - performing ISO8601 date/time parsing and date/time calculation (shared by Timeline and Timeplot). - generating parameterized DOM fragments. - a basic window manager that supports modal layers of dialog boxes and menus. - some data structures, such as the event index. It'd definitely be good to factor those out as jQuery extensions, or to include any existing jQuery extension that implements them. And then switch code inside the other widgets over to using jQuery's implementation of the same features in SimileAjax. (It'd also be good to replace the jquery file in SimileAjax with its minified version.) The inclusion of jquery was intended to be the first step toward switching the other widgets over. It got included so that developers of the other widgets could start to switch over at their own paces. This was because it would take too much coordination to get all of the switching done in one shot, so it must be spread over time. However, with many major changes to the Simile project and the original developers' employment, such switching is kept on the back burner. I'm totally supportive of completing the switch over and tying up of loose ends (such as adding explicit widget version numbers, detecting any existing jQuery and not including another version). I'd greatly appreciate any help on it. David Larry Kluger wrote: > > Hi Nick, > > Thank you for your great message. And thank you for your work on TimeMap. > > Comments are below. I'm sure that David H and others will also have > thoughts. > > Regards, > > Larry > > > ------------------------------------------------------------------------ > *From:* Nick R <[email protected]> > *To:* SIMILE Widgets <[email protected]> > *Sent:* Wednesday, February 18, 2009 4:50:15 PM > *Subject:* Version question and comments > > > Hello - > > I'm the developer of TimeMap, a JavaScript library that relies on > Timeline. So far, I've been using the deprecated Timeline 1.2 API, but > I want to make the library compatible with newer versions as well. > This brings up a couple of questions and comments that I thought might > be appropriate for this list, and I'd love to get your thoughts. > > Questions: > > 1. Is there any reliable way to determine what version of Timeline has > been loaded? > > [A good idea. I've added issue 60 to the issues system at the Google > code site and will add it. > One question is what should the value be for the trunk version. > The trunk version is beyond 2.2.0 but will not be the exact same as > 2.3.0 until 2.3.0 is out. > So should the current trunk version be "2.2.0+"? (But then its a > string, not a number.) > ] > > I'd like the library to transparently work with v.1.2 and > v.2.2.0, without the end developer having to specify which version > they're using. I'm pretty sure I can do this in a messy way by > checking for specific objects or attributes (e.g. {if > ("DurationEventPainter" in Timeline) ...} ), but I was hoping there > might be a more consistent way to check this. It's a little > hypocritical of me to ask, because I haven't provided this in my own > library (hmm... adding now...), but what I really want is to be able > to check a static var like Timeline.version that's consistently > accurate. > > 2. Is there any point in supporting 2.x versions earlier than 2.2.0? > Or is everyone who uses 2.x using 2.2.0 or the development version? > [Correct, 2.1.0 was really just a placeholder to fix some > inconsistencies in the svn revision numbers vs the releases. > And really, the current trunk is where people should be. 2.2.0 works > well, but a number of things were only partially done or not yet > handled within 2.2.0. See the trunk changes.txt for all of the > details. I believe that the trunk ver works well and is self > consistent with one exception: the trunk zip files need to be updated > to handle a change in the underlying Simile Ajax library. But > downloading the trunk via svn works well.] > > In case you're wondering why I want to support the 1.2 version at all, > there are several reasons. First, it seemed when I started this > project that the 1.2 version was the most stable; this may no longer > be the case. > [Depends on what you mean by "stable." It has a number of bugs, most > minor. It also has many fewer features than ver 2. But if you want to > continue to support it, fine by me. The 1.2 branch will not disappear, > but it won't be updated either.] > > Second, I've been worried about the ballooning size of > the 2.x versions. According to Firebug, Timeline 2.2.0 is loading a > full 100K more script, even when bundled, than Timeline 1.2. > [Interesting. A couple of things come to mind: > 1. Ver 2.2.0 has two painters in it and localization files. So > depending on the usage, some of that can be removed. > 2. Probably a bigger issue is the size of jQuery, it may well have > grown in the year or so between 1.2 and 2.2.0. > 3. As noted, more features. Not sure of the right answer there. I have > pushed back against some feature ideas that I felt did not have to be > part of the core library. > ] > > I especially have mixed feelings about the wholesale inclusion of > jQuery 1.2.3 - first, because my understanding is that 1.3.1 is the > latest stable version, and 1.2.6 is the latest 1.2.x version, so if I > want to use the latest stable releases I can't without double-loading > the library. > [The trunk version of Simile Ajax uses JQuery 1.2.6. So an issue is > for me or others is to do a release of the Simile Ajax subproject to > pick up the 1.2.6 JQuery and a number of bug fixes and features that > are in the trunk Ajax project. After that, the next thing would be to > try jQuery 1.3.1. > > To answer your bigger question of the inclusion of jquery: > a) The Ajax api file is designed to not load jquery if it is already > loaded. But I could easily understand if that sw is not working right, > it probably isn't tested much, if at all. If you could test it, that'd > be great. > b) I agree that the inclusion of jquery should be looked at again. I'd > prefer the writing of an api and compatibility layer that would enable > libraries other than jquery to be used once the correct compatibility > layer was written. Personally, I prefer the YUI library for anumber of > reasons. Prototype is also popular. > c) Issues at this level require the buy-in of the Timeline and Simile > architects. -- It will need to be discussed, alternatives considered, etc. > ] > > It also seems like there's a ton of functionality in > jQuery that's duplicated in the SIMILE Ajax library - are you planning > to eventually move entirely to jQuery, or will you keep the duplicate > features? > [Another good point. > I've noticed the same issue. This sort of maintenance and refactoring > is important to do, but never seems to get much bandwidth :-). > I do think that it is important to move as much functionality as > possible to a regular library and out of Timeline and the other > projects. -- Hopefully via a compatibility api and layer that would > not limit the choice of the underlying library. But I think other > issues are higher priority: > 1) More reference documentation > 2) More cookbook-style docs (also know as recipes) > 3) Tests, perhaps via http://seleniumhq.org/ That way we can tell if > the changes are breaking anything.... > There have been a number of changes to the Timeline code base which > broke things. I don't really like to spend my open source time testing > others' code, finding errors and then backing out their changes. So > I've put emphasis on adding to the example files which I use as "poor > man's tests." The real thing (Selenium or similar) would be far > better. If you could help with that issue (or others), that'd be great! > ] > > Sorry if this comes on strong - I think Timeline is a great project; I > just wanted to voice a couple of comments as a developer who uses the > library a lot. Let me know what you think - thanks! > > [ MOST important comment: > THANK you for your time with Timeline and the related Simile projects. > > We'd really really love your help with the project, at any level. > Please let us know what parts are of most interest... > > Regards, > Larry > ] > > > -Nick > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en -~----------~----~----~----~------~----~------~--~---
