Introducing www.simile-widgets.org
David Huynh
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
Larry Kluger
Congratulations on the new site!
Thank you for your ongoing work on the software and the server.
Regards,
Larry
From: David Huynh <dfh...@alum.mit.edu>
To: simile-...@googlegroups.com; General List <gen...@simile.mit.edu>
Sent: Tuesday, March 10, 2009 3:21:53 PM
Subject: Introducing www.simile-widgets.org
Jörn Clausen
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.
> 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.
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 technically curious: the server that hosts
> www.simile-widgets.org is a virtual server [...]
For the even more curious: What virtualization solution have you chosen?
BTW: The coverflow widget is really nifty. Hope you have checked any
IP claims from Apple :)
--
Joern Clausen
joe...@gmail.com
http://www.oe-files.de/oefiles/
http://thebloeg.blogspot.com/
David Huynh
> Hi David and Team!
>
> 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.
>
Yes, we're still live and strong here, 712 members on the simile-widgets
mailing list as of today!
>> 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.
>>
>
> 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.
>> For the technically curious: the server that hosts
>> www.simile-widgets.org is a virtual server [...]
>>
> For the even more curious: What virtualization solution have you chosen?
>
I'll leave this question for Stefano.
> BTW: The coverflow widget is really nifty. Hope you have checked any
> IP claims from Apple :)
>
There are many Flash-based implementations of Coverflow-like widgets out
there that are not by Apple. What's different about Runway is that it's
easy to drive Runway through Javascript. In the future, I'll integrate
it into Exhibit so you can get faceted browsing, etc. in conjunction
with the pretty visualization... It was also done because I wanted an
excuse to learn Flash/Actionscript, which will be useful for more
advanced visualizations later on.
David
Stefano Mazzocchi
[snip]
>> For the even more curious: What virtualization solution have you chosen?
>>
> I'll leave this question for Stefano.
And I'll leave this question to Alex, who's the one that setup the
system. I honestly don't know.
--
Stefano Mazzocchi Application Catalyst
Metaweb Technologies, Inc. ste...@metaweb.com
-------------------------------------------------------------------
David Huynh
> Hi David and Team!
>
> 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.
getting more people to know about them. That might mean linking to them
(even just to give credits when you use them), blogging about them,
bookmarking them on Digg, del.icio.us, etc.
Every bit helps! :-)
Thanks,
David
Herman Tolentino
More power to SIMILE widgets!
Herman
Herman Tolentino, MD
Email: herman.t...@gmail.com
Web: http://blog.epispider.net
Skype: hermant...@skype.net
Nick R
> > 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.
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
Jörn Clausen
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.
marcel...@fortuna-werbeagentur.de
the new site is a big step forward for the WorldWideWeb (o: .
I wish you a sucessfull future with those outstanding widgets. You
guys know you did a great job, we know this too and appreciate every
minute of your effort.
Keep on developing! I will do my best to let more people get in touch
with this project in germany!
Cheers!
Nick R
developer using TimeMap, which depends on the Timeline API:
> We got a big big problem this morning with the add in timeline :
> "Thank you for using SIMILE Timeline. However, your page is
> referencing an old version of Timeline at a location soon to be
> deprecated. Please upgrade to the latest version at the latest
> location at http://www.simile-widgets.org/timeline/."
>
> Any solution to solve that problem ?
> We have few thousand visitors and the new law can be voting today...
This is exactly what I'm talking about - every developer using the
older version of Timeline for a time-sensitive application - that is,
almost anything live on a website with more than a few visitors per
day - just got the rug pulled out from under them. Yes, this person
can use a local version of the old code, but that's not what was
promised by the API - the Timeline site has explicitly said "use our
API online, don't bother to download" since its inception.
If you want to promote the SIMILE code with developers, it's not a
good idea to cause them this kind of misery. Please, please take the
deprecated notice out of the code.
Thanks -
-Nick
David Huynh
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 Rabinowitz
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 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
David Huynh
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
Nick Rabinowitz
I'm not trying to criticize; I'm trying to help the project, because I believe that the trust of your developers is at stake if you break your API at this point. That's why I'm hoping you can find a way to continue to support the old URL, while offering clear indications to developers that the old version is considered deprecated and you feel they'd be better off using the newer versions, perhaps as local installations. My Firebug suggestion wasn't meant as a solution to the question of how to notify developers; it was meant as one of several measures (the most obvious being website instructions) you could use to get people to migrate without breaking their trust.
I apologize if it seems like I'm making a big deal out of this, but I felt quite upset when I saw that a service I had trusted was injecting unwanted public messages on sites and projects I had worked on. I truly appreciate that you took the notice down, and I'll look into moving my own projects to the newer version of Timeline. But I'm likely to use local copies of the code from here on out.
-Nick