>  http://api.simile-widgets.org/[widget]/[version]/[widget]-api.js

> The old URLs for the js APIs at static.simile.mit.edu continue to exist,
> but they won't be further updated and, in the future, they will start to
> redirect to the new locations.

> Congratulations! That is really great news. Good to know that these
> widgets are not suddenly falling off the edge of the world. Thanks for
> your continuous effort in providing this valuable service.

>>  http://api.simile-widgets.org/[widget]/[version]/[widget]-api.js

>> The old URLs for the js APIs at static.simile.mit.edu continue to exist,
>> but they won't be further updated and, in the future, they will start to
>> redirect to the new locations.

> What about the really old (1.x ?) version of Timeline? I still haven't
> had the time to rewrite my application. Should/can/must I switch to
> the new server?

> For the even more curious: What virtualization solution have you chosen?

> I'll leave this question for Stefano.

> Congratulations! That is really great news. Good to know that these
> widgets are not suddenly falling off the edge of the world. Thanks for
> your continuous effort in providing this valuable service.

> When the MIT SIMILE project finished its round of funding in May 2008,
> we didn't have enough time, resources and (frankly) energy to properly
> 'spin-off' all the goodies that that project managed to develop over the
> years. It is therefore with pride and relief that we (finally) announce
> today the availability of

>   http://www.simile-widgets.org/

> a site where the diverse and healthy community of open source
> contributors becomes completely in charge of the future of the
> javascript widgets that came out of the SIMILE project.

> The hardware, bandwidth and power for www.simile-widgets.org was kindly
> donated by the MIT Libraries, which are committed to maintain it alive
> just like any technical service they offer on the web. We wish to thank
> the MIT Libraries (and in particular MacKenzie Smith, Associate Director
> for Technology at the MIT Libraries and former PI for the SIMILE
> Project) for making this happen.

> All the content, APIs, web pages and web services required for the
> simile widgets to function have been ported to www.simile-widgets.org
> and their code added to the svn repository. This finally breaks the
> dependency on simile.mit.edu and makes the two completely separate
> entities, which are now free to take different paths in the future.

> With this move, we are also releasing new versions of the widgets, in
> particular:

>  Ajax 2.2.1 - now including jQuery 1.3.2
>  Timeline 2.3.1 - no change from 2.3.0 on simile.mit.edu
>  Exhibit 2.2.0 - some changes [1]
>  Timeplot 1.1 - no change from 1.0 on simile.mit.edu

> These widgets' APIs are available at URLs of this pattern:

>  http://api.simile-widgets.org/[widget]/[version]/[widget]-api.js

> The old URLs for the js APIs at static.simile.mit.edu continue to exist,
> but they won't be further updated and, in the future, they will start to
> redirect to the new locations.

> We have also moved the painter and babel services (which are used by
> Exhibit) over to:

>  http://service.simile-widgets.org/painter/painter
>  http://service.simile-widgets.org/babel/

> and the new hardware has even more resources than the 5 years-old
> simile.mit.edu box, so we should be in great shape serving all the
> required requests from those services.

> For the technically curious: the server that hosts
> www.simile-widgets.org is a virtual server and the SIMILE Widgets main
> developers have root access to the box. This helps tremendously because
> we can install our own services and maintain it ourselves, just we did
> for simile.mit.edu (which allowed us to innovate freely on the
> client/server mix of javascript widgets).

> -- The original SIMILE Project team

> You should definitely switch to the new server and new API versions.

> Any solution to solve that problem ?
> We have few thousand visitors and the new law can be voting today...

> I didn't even realize that my mashup now makes me look like an idiot.
> A note to this list some *weeks* before inserting this change would
> have been nice. Or did I miss anything? I haven't checked: Is an
> "untainted" version of the old API available via simile-widgets.org,
> so that I just can replace the URL in my HTML code?

> Changing to the new API is not that straight forward, it's not a
> drop-in replacement. I know I am missing some nice features of the new
> Timeline, in which Larry invested much time and effort. But I'd really
> like to stick to the old API for some time longer - at least I don't
> want to do the change in panic mode.

> --
> Joern Clausen
> joe...@gmail.comhttp://www.oe-files.de/oefiles/http://thebloeg.blogspot.com/

>>> What about the really old (1.x ?) version of Timeline? I still haven't
>>> had the time to rewrite my application. Should/can/must I switch to
>>> the new server?

>> You should definitely switch to the new server and new API versions.

> While I'm happy about this development, I have to say I'm concerned by
> the choices to a) potentially remove the current timeline API, and b)
> to inject the "you're using a deprecated version notice." I've already
> voiced on this list some reasons why I, as a developer, might choose
> to use the old SIMILE API - it's a smaller load, the default event
> painter is (IMHO) nicer, it's not loading an outdated version of
> jQuery, etc. This doesn't mean that I won't move my work to the new
> version, but it does mean that I would prefer not to be forced to move
> prematurely to the new code.

> My real issue here, though, is the injected notice. It would be fine
> if this was only developer-facing, but it has an immediate, end-user
> effect on every page currently using the API. That makes any current
> project using the old API look broken and unprofessional. It also
> effectively breaks any library or tool depending on the API, making
> those projects look broken to people using them who may lack the
> ability to fix the problem. You've just made any developer using the
> older API look like an idiot to their users, co-workers and clients.
> Please, please don't break the older API in this way unless there's an
> actual security risk to using this code.

> The original idea of the SIMILE code was that it could be used like
> the Google Maps code - with no download or installation. Any API is
> effectively a contract with other developers that their code will not
> be broken by future developments in your project. Unless there is a
> security reason to change the API, I for one would love to see this
> contract upheld. If the issue is MIT's hosting, simply have
> http://simile.mit.edu/timeline/api/timeline-api.js redirect to the old
> 1.2 version on the new server - I'm sure MIT will support that much.

> Thanks for your consideration here. I'm glad to see the project moving
> along, and I'm glad it has a new home - but please, out of
> consideration for your many users, don't break the older API unless
> it's truly necessary.

> -Nick

> Nick,

> Thank you for raising your concern. Timeline 1.2 is still available here
> (without injected notice)
>    http://static.simile.mit.edu/timeline/api/
> but not here
>    http://simile.mit.edu/timeline/api/
> <http://static.simile.mit.edu/timeline/api/>
> I believe that we have mentioned that the official API URLs are those in
> the static.simile.mit.edu domain. The static domain was created in early
> 2007 for static files while simile.mit.edu includes dynamic services
> like painter and babel.

> The decision for the deprecating notice was made jointly by me and
> Stefano. We did consider current usage of the really old Timeline API.
> - The originally Simile project ran out of funding in May 2008, but we
> still serve all the APIs many months after that. If we were a company
> who went bankrupt, the service would not continue that long afterward.
> - Timeline 2.0 went out in April 2008, and I personally keep on
> recommending upgrade to 2.x on this mailing list. However, we still make
> 1.2 available on the static domain.
> - From our server logs, the sites that most heavily burden traffic to
> simile.mit.edu/timeline/api don't actually use it. Their webmasters
> included the API to try it out and forgot it there.
> - I believed that people who listened in on this mailing list would
> already know about the static domain, and those who didn't couldn't be
> reached anyway.

> I have disabled the injected notice for now. However, the problem
> remains: how can people using the really old version of Timeline be
> notified so that they would upgrade, before simile.mit.edu, and then
> static.simile.mit.edu, are taken off-line altogether eventually? I don't
> think that sending a notice here would (1) reach them all, (2) get them
> to act in any given time frame. If you have a better solution, please
> let us know!

> David

> Nick R wrote:
> > Hello all -

> >>> What about the really old (1.x ?) version of Timeline? I still haven't
> >>> had the time to rewrite my application. Should/can/must I switch to
> >>> the new server?

> >> You should definitely switch to the new server and new API versions.

> > While I'm happy about this development, I have to say I'm concerned by
> > the choices to a) potentially remove the current timeline API, and b)
> > to inject the "you're using a deprecated version notice." I've already
> > voiced on this list some reasons why I, as a developer, might choose
> > to use the old SIMILE API - it's a smaller load, the default event
> > painter is (IMHO) nicer, it's not loading an outdated version of
> > jQuery, etc. This doesn't mean that I won't move my work to the new
> > version, but it does mean that I would prefer not to be forced to move
> > prematurely to the new code.

> > My real issue here, though, is the injected notice. It would be fine
> > if this was only developer-facing, but it has an immediate, end-user
> > effect on every page currently using the API. That makes any current
> > project using the old API look broken and unprofessional. It also
> > effectively breaks any library or tool depending on the API, making
> > those projects look broken to people using them who may lack the
> > ability to fix the problem. You've just made any developer using the
> > older API look like an idiot to their users, co-workers and clients.
> > Please, please don't break the older API in this way unless there's an
> > actual security risk to using this code.

> > The original idea of the SIMILE code was that it could be used like
> > the Google Maps code - with no download or installation. Any API is
> > effectively a contract with other developers that their code will not
> > be broken by future developments in your project. Unless there is a
> > security reason to change the API, I for one would love to see this
> > contract upheld. If the issue is MIT's hosting, simply have
> > http://simile.mit.edu/timeline/api/timeline-api.js redirect to the old
> > 1.2 version on the new server - I'm sure MIT will support that much.

> > Thanks for your consideration here. I'm glad to see the project moving
> > along, and I'm glad it has a new home - but please, out of
> > consideration for your many users, don't break the older API unless
> > it's truly necessary.

> > -Nick

> Thanks for your reply, and thank you for disabling the notice.

> My concern here is that a developer working pre-2007 - only a little
> more than a year ago - would have seen instructions encouraging them
> to hotlink to http://simile.mit.edu/timeline/api/ , with the assurance
> that this URL would work in perpetuity. If this wasn't going to be
> possible, the instructions should have told developers to download a
> local copy of the code. If you want developers to use and trust the
> code, posting an online API has to be seen as a firm agreement to
> maintain it. In my opinion, the only reason to break this agreement
> should be the discovery of an unpatchable security hole, or the kind
> of project failure where you no longer care whether people use your
> code (e.g. corporate bankruptcy, etc).

> I admit that that problem of how to politely break the API for
> thousands of anonymous developers is a difficult one, and that's why,
> if possible, I think you should avoid breaking it. In the current
> situation, I would have thought a simple redirect to the v1.2 code on
> the static site or the new site should remove the need to actually
> host the simile.mit.edu <http://simile.mit.edu> code, without placing
> an undue burden on those servers.

> One possible idea would be to insert the message in a developer-facing
> way, through Firebug. This makes the assumption that many developers
> use Firebug, and might at least work for anyone doing active
> development with the old API:

> if (!window.console) {
>  window.console = new function() {
>    this.log = function(str) {};
>  };
> }
> console.log("You are using an outdated version of the API. Please
> upgrade!");

> This is surely less effective than the inserted div, but it does far
> less to break the trust of developers using your code.

> Thanks again for your consideration here -

> -Nick

> Hi Nick,

> Thanks for the suggestion regarding using Firebug to notify developers.
> I personally don't think it will be effective.

> I wish we could make the promise to serve the APIs in perpetuity, but
> that's simply impossible. Even Google can never make such a promise. :-)
> I admit the encouragement to hotlink on http://simile.mit.edu/timeline/
> can be misunderstood to imply such a promise, so we'll be more careful
> with the wording in the future.

> David

> Nick Rabinowitz wrote:
> > Hello David -

> > Thanks for your reply, and thank you for disabling the notice.

> > My concern here is that a developer working pre-2007 - only a little
> > more than a year ago - would have seen instructions encouraging them
> > to hotlink to http://simile.mit.edu/timeline/api/ , with the assurance
> > that this URL would work in perpetuity. If this wasn't going to be
> > possible, the instructions should have told developers to download a
> > local copy of the code. If you want developers to use and trust the
> > code, posting an online API has to be seen as a firm agreement to
> > maintain it. In my opinion, the only reason to break this agreement
> > should be the discovery of an unpatchable security hole, or the kind
> > of project failure where you no longer care whether people use your
> > code (e.g. corporate bankruptcy, etc).

> > I admit that that problem of how to politely break the API for
> > thousands of anonymous developers is a difficult one, and that's why,
> > if possible, I think you should avoid breaking it. In the current
> > situation, I would have thought a simple redirect to the v1.2 code on
> > the static site or the new site should remove the need to actually
> > host the simile.mit.edu <http://simile.mit.edu> code, without placing
> > an undue burden on those servers.

> > One possible idea would be to insert the message in a developer-facing
> > way, through Firebug. This makes the assumption that many developers
> > use Firebug, and might at least work for anyone doing active
> > development with the old API:

> > if (!window.console) {
> >  window.console = new function() {
> >    this.log = function(str) {};
> >  };
> > }
> > console.log("You are using an outdated version of the API. Please
> > upgrade!");

> > This is surely less effective than the inserted div, but it does far
> > less to break the trust of developers using your code.

> > Thanks again for your consideration here -

> > -Nick