SWiK
» tagged pages
» logout

sorted by: recent | see : popular
Content Tagged with Gears + front

YouTube Uploader now using Gears, and what people missed in Gears 0.4

While we posted about the Gears 0.4 features a lot of the press only really talked about the Geolocation piece.

I think that is important, and posted on that too, but Brad's piece discussed the full gamut including the Blob API, resummable HTTP, and Desktop API improvements to allow controlled file system access. The example that Brad built was the upload movie tool which ties this all together.

Check out the source code and you will see the parts and pieces in action:

Geolocation

PLAIN TEXT
JAVASCRIPT:
  1.  
  2. MovieTool.prototype.getLocation = function(callback) {
  3.   var geolocation = google.gears.factory.create('beta.geolocation');
  4.   if (!geolocation.getPermission('Upload Movie Tool', '',
  5.                                   'This sample can use your '
  6.                                 + 'geographic coordinates in order to tag '
  7.                                 + 'uploaded videos with your location')) {
  8.     document.getElementById('location').innerHTML = 'Permission denied';
  9.     callback();
  10.     return;
  11.   }
  12.  
  13.   var self = this;
  14.   geolocation.getCurrentPosition(
  15.     function(p) {
  16.       var addr = p.gearsAddress;
  17.       var address = addr.city + ', ' + addr.region + ', ' + addr.country;
  18.       var latitude = p.latitude;
  19.       var longitude = p.longitude;
  20.       self.geoAddress_ = address + ' (' + latitude + ', ' + longitude + ')';
  21.       document.getElementById('location').innerHTML = self.geoAddress_;
  22.       callback();
  23.     },
  24.  
  25.     function(err) {
  26.       var msg = 'Error retrieving your location: ' + err.message;
  27.       document.getElementById('location').innerHTML = msg;
  28.       callback();
  29.     },
  30.    
  31.     {
  32.       enableHighAccuracy: true,
  33.       gearsRequestAddress: true,
  34.       gearsLocationProviderUrls: ['http://www.google.com/loc/json']
  35.     }
  36.   );
  37. }
  38.  

HTTPRequest

PLAIN TEXT
JAVASCRIPT:
  1.  
  2.   var req = google.gears.factory.create('beta.httprequest');
  3.   req.open('GET', '/list');
  4.   var self = this;
  5.   req.onreadystatechange = function() {
  6.     if (req.readyState == 4) {
  7.       if (req.status == 200) {
  8.         var loadingMsg = document.getElementById('loadingFilesMsg');
  9.         loadingMsg.parentNode.removeChild(loadingMsg);
  10.         self.movieList_ = eval(req.responseText);
  11.         for (var i = 0; i <self.movieList_.length; i++) {
  12.           var entry = self.movieList_[i];
  13.           // associative entry for fast lookup based on filename
  14.           self.movieList_['_' + entry.filename] = entry;
  15.           var status = 'Uploaded'
  16.           var percent = '100%';
  17.          
  18.           // was this movie partially uploaded during an earlier browser
  19.           // session?
  20.           if (entry.uploaded == false && entry.blob == null) {
  21.             status = 'Partially uploaded; re-select file to continue uploading';
  22.             percent = Math.round((entry.bytesUploaded / entry.length) * 100) + '%';
  23.           }
  24.          
  25.           // is this movie too large?
  26.           if (entry.uploaded == false && entry.length> self.MAX_FILE_SIZE) {
  27.             status = 'File too large';
  28.             percent = 'N/A';
  29.           }
  30.          
  31.           self.drawRow(entry.filename, entry.geoAddress, status, percent);
  32.         }
  33.       }
  34.      
  35.       callback();
  36.     }
  37.   }
  38.  
  39.   req.send();
  40. }
  41.  
  42. ....
  43.  
  44. // sending a piece
  45.   req.open('POST', uploadURL);
  46.  
  47.   req.setRequestHeader('Content-Disposition',
  48.                         'attachment; filename="' + fileName + '"');
  49.   req.setRequestHeader('Content-Type', 'application/octet-stream');
  50.   req.setRequestHeader('Content-Range', 'bytes ' + byteRange);
  51.  
  52.  

Desktop API

PLAIN TEXT
JAVASCRIPT:
  1.  
  2. MovieTool.prototype.selectFiles = function() {
  3.   var desktop = google.gears.factory.create('beta.desktop');
  4.   var self = this;
  5.   desktop.openFiles(
  6.     function(files) {
  7.       for (var i = 0; i <files.length; i++) {
  8.         var entry = {filename: files[i].name, uploaded: false,
  9.                             length: files[i].blob.length,
  10.                             blob: files[i].blob, bytesUploaded: 0,
  11.                             geoAddress: self.geoAddress_, uploadRetries: 0};
  12.         if (self.movieList_['_' + entry.filename]) {
  13.           // was previously uploaded at an earlier browser session
  14.           var oldEntry = self.movieList_['_' + entry.filename];
  15.           if (!oldEntry.uploaded) { // partial upload
  16.             oldEntry.length = entry.length;
  17.             oldEntry.blob = entry.blob;
  18.             var percent = Math.round((oldEntry.bytesUploaded / oldEntry.length) * 100);
  19.             self.updateStatus(oldEntry.filename, 'Not uploaded', percent + '%');
  20.           } else {
  21.             self.updateStatus(oldEntry.filename, 'Uploaded', '100%');
  22.           }
  23.         } else { // new file
  24.           // associative entry for fast lookup based on filename
  25.           self.movieList_['_' + entry.filename] = entry;                   
  26.           self.movieList_.push(entry);
  27.          
  28.           var status = 'Not uploaded';
  29.           var percent = '0%';
  30.           // is this movie too large?
  31.           if (entry.length> self.MAX_FILE_SIZE) {
  32.             status = 'File too large';
  33.             percent = 'N/A';
  34.           }
  35.          
  36.           self.drawRow(files[i].name, self.geoAddress_, status, percent);
  37.         }
  38.       }
  39.      
  40.       document.getElementById('movieUpload').disabled = false;
  41.       document.getElementById('clearMovies').disabled = false;
  42.     },
  43.    
  44.     { filter: ['video/quicktime', '.wmv', 'video/avi'] }
  45.   );
  46. }
  47.  

It turns out that YouTube has implemented a multifile upload using Gears which puts this into practice. As someone who uses YouTube a lot to upload files this is very welcome indeed, and I can't wait to see more sites use it now the building blocks are there in a different way (can always use Flash / other controls in the past).

Ajax: Ajaxian

GALGWT 1.0… it isn’t a land next to Mordor

GWT has long had a project that aimed to give rich support for Google APIs called GALGWT, or "Google API Libraries for Google Web Toolkit".

This project has stepped up to higher gear recently, and we have seen the GALGWT 1.0 release candidate appear.

What is in GALGWT?

The project is a collection of libraries that provide Java language bindings
and API specific 'plumbing' for some Google JavaScript APIs. The goal is to
make it easy for developers to use these JavaScript APIs with GWT. Libraries
available at this time include a new version of Gears, as well as new
libraries for Gadgets and the Google AJAX Search API.

Gears 1.1 Library

A new version of the Gears library is available. In addition to the earlier
version's support for the Gears LocalServer, Database, and WorkerPool, 1.1
adds integrated support for offline applications and updated sample
applications. The bindings have also been refactored to use GWT 1.5
JavaScript overlay types and a new package hierarchy.

Gadgets 1.0 Library

The Gadgets library simplifies gadget development with GWT by automatically
generating a Gadget specification from Java source and inserting a selection
script in the specification much like a regular GWT project. After compiling
your gadget with GWT, all files are in place to publish your gadget. This
version currently supports the legacy Gadgets API based on the _IG_...
namespace.

Google AJAX Search 1.0 Library

The Google AJAX Search API lets you put Google Search in your web pages,
including Web, Local, and Multimedia searches. This library allows you to
access the API from Java code compiled with the GWT compiler without having
to write additional JavaScript code.

Ajax: Ajaxian

Tombs of Asciiroth: GWT, Gears, and AIR enabled RPG Game

Alx Dark has created The Tombs of Asciiroth a fully functional roguelike-meets-puzzle-arcade game.

Asciiroth is a a complete, functional, open source game, written using GWT, and distributed either as an Adobe AIR application, or as a game you can play over the web. In the latter case, it uses Gears to provide saved game support. (So bottom line is you can play it using AIR or Firefox... IE is too slow, Opera/Safari aren't supported by Gears.) It also has a map editor that is distributed as an Adobe AIR application.

It is very cool to see applications written using Ajax, and then using both Gears for in-browser functionality, and AIR for desktop deployment.

Ajax: Ajaxian

PubTools Search: Fast client-side searching with Gears

Brad Neuberg has built a very easy to use client side search tool called PubTools Search using Gears. The project is open source and provides a great avenue to share knowledge on Gears itself.

To accompany the code, Brad wrote a detailed article:

Did you know that you can use Gearsto do fast, client-side searching of data, similar to a client-side search engine? Gears bundles Full-Text Search (FTS) abilities right into its local, SQLite database. MySpace, for example, uses this feature with their MySpace Mail application, downloading all of a user's messages for fast, client-side search. Because all of the data is local, you can do nifty things like search over the data in real-time as the user types, something that is much harder if you have to query over the network to a server to do the searching.

Would you like to add the same kind of fast, local searching to your own web page and web applications? This article introduces you to PubTools Search and the Gears features that power it, namely Full-Text Search and Workers. PubTools Search is an open source JavaScript library that drops a client-side search engine right into your page. You configure it with basic HTML plus a list of URLs to index. Once loaded, a search form that uses the local Gears full-text search abilities will appear in your page to quickly and locally search over the documents in real time as a user types into the search field.

Brad sat down with me to discuss the project, some of the best practices, and his use of Dojo.

Ajax: Ajaxian

Gears turns one; Old enough to power MySpace message search

Chris Prince posted about Gears turning one year old. It was launched at last years Google Developer Day, and here we are at Google I/O a short year later.

There was some fun news around Gears yesterday. Firstly, MySpace is using Gears to enable users to search their MySpace messages:

One feature that they were lacking was the ability for MySpace users to actually search their MySpace messages. To go through mail, users have to page through all of their messages until their find the right one. Not optimal to say the least!

They could have tried to do search on the server side, but it can be a very expensive operation, and when you are at MySpace scale, you have to choose your battles.

With server side search out, they looked at doing the work on the client. They ended up with a Gears powered solution that not only searches, but gives back results in real-time as you are typing it in. This means that you can stop typing earlier, as you find what you are looking for.

The MySpace team has been a pleasure to work with, and were very fast to put the pieces together of an Full Text Search datastore, and the WorkerPool to offload the search without hanging the browser.

This is yet another use of Gears that isn't just about "offline", which we are seeing more and more. In fact, Chris Prince gave a talk yesterday that showed prototypes and examples of Gears that people are exploring. There was exciting stuff in there such as:

  • Multiple File Upload: Using the File System API, Chris demonstrated a multiple file upload experience. Selecting multiple files, finally!
  • Resumable File Upload: He then showed a YouTube mockup that showed uploading multiple files, seeing their status, and after a connection died showing how the file resumes and doesn't start from 0% All using a ResumableRequest that sat on top of the Blog API and HttpRequest
  • Find nearby stuff! Next up was a demo that let Chris search for beer, resulting in local places around the Moscone Center. This example used the Geolocation API which uses GPS, Wifi IDs, Cell IDs, and IP address to work out where you are
  • Notifications: Love the Windows toasters, or Growl-ing on the Mac? Chris showed notification examples

Ajax: Ajaxian

Speed Up! with Wordpress and Gears

Reposted from my personal techno.blog

I was sitting on the tube a few months ago in London when I looked up to see Matt Mullenweg, Om Malik, and another nice chap whose name escapes me. A little random to bump into them in the middle of London, but we were all in town for the "Future of Web Apps" conference. I had the fortune to chat with Matt a little about Gears and Wordpress. The marriage of which would make me a happy man as I use both technologies on a daily basis (this blog and Ajaxian both run Wordpress).

Brad Neuberg got to working with the Wordpress team, and after a short IRC session they had great progress. At first it can seem daunting "Oh man, won't it be a ton of work to rewrite Wordpress to work offline?"

Speed Up!

This leads us to this post by James who did an "svn up" recently, and saw new support for Gears which lead to some pleasant surprises:

As a side note and introduction to what has been sped up, here’s a little rant.

I personally LOVE the changes that were implemented with WordPress 2.5.

But, some of the new features (and features I’ve just started using now that I use the Visual Editor) just aren’t as cool thanks to the not-so-great internet speeds in South Africa.

For example, if you want to create a link. Every time you click the link icon in the editor’s toolbar, it has to download the same stuff over and over…

Well, it looks to me like the WordPress Google Gears implementation has solved that. The link and the “insert embedded media” popups are now instantaneous!

Thank you to whoever decided to do this.

It also seems that switching between each “pane” in the admin section is a LOT faster… Believe me, working on the South African tubes (via iBurst), this makes a HUGE difference!

I am really proud of the Gears team whenever I open up Google Docs, Reader, Zoho, or any other application that uses Gears to let me access the application while offline. There have been situations where it really saved me, and offline is an important boundary.

However, Gears is so much more than offline, and it is really exciting to see "Speed Up!" as a link instead of "Go Offline?"

This is just the beginning. As the Gears community fills in the gaps in the Web development model and begins to bring you HTML5 functionality I expect to see less "Go Offline" and more "Speed Up!" and other such phrases. In fact, I will be most excited when I don't see any such linkage, and the applications are just better.

With an embedded database, local server storage, worker pool execution, desktop APIs, and other exciting modules such as notifications, resumable HTTP being talked about in the community.... I think we can all get excited.

Kudos to the Wordpress team for finding a great way to increase the performance of their great application, and I can't wait to see how you use Gears in the future.

Ajax: Ajaxian

Addressbook: An example of the Form History Pattern

One of the examples that Ben and I give in our State of Ajax talk at Google I/O today revolves around form history.

We were thinking about the case for Undo on the Web that Aza Raskin is proposing and it got us thinking about the usage patterns of form data.

An example that got me was the Address Book application on the Mac. I find myself storing past addresses in the general "Notes" section at the bottom, but what if history was built into the system so I could go back in time? This could be a nice metaphor in general that goes beyond undo.

I took this use case and put together a working example that uses Gears to store the history locally so it can be speedy through the history.

The slider component comes from Script.aculo.us, and you can check out all of the code.

In the video below I show the application in action and then do a quick code walk through:


This is just the beginning of course. A slider if fun, but it would probably be more usable if it was simply left and right arrows that click through the versions, or at least putting tacks onto the slider.

Ajax: Ajaxian

Growl for Windows and a Web Notification API

I have talked before about the desire for a Notification API on the Web. As a Mac user, I would love to see Growl from JavaScript, and there have been libraries written from as far back as protoGrowl.

The difference is between a JavaScript API that does notifications on the desktop, versus trying to get little custom notifications inside the browser window itself. I am talking about the former.

Brian Dunnington has developed Growl for Windows, and with his latest version, he allows you to talk to the system via JavaScript.

You can check out the growl.js library.

What was interesting was the implementation side, and the paths Brian went down to get this working. I asked him for his thoughts, and he wrote up the following:

One of the biggest new features in the latest version of Growl for Windows (v1.2 alpha) is the ability to receive notifications from websites running in your browser. i spent quite a bit of time working out the best way to handle this functionality and thought i would share my thought process.

since Growl can already receive notifications over the network, i figured that it would be easiset to build the Web-based notification system on top of that. Growl receives network notifications using a simple protocol over UDP. ok - first hurdle: browsers and javascript dont do UDP, so i figured i would have to go with some kind of add-on. i wanted the solution to work cross-browser, so Firefox extensions and ActiveX plug-ins were ruled out. i also wanted the solution to work for the broadest range of people, so i didnt want to write a custom add-on (a la Gears). i knew that Flash and Silverlight both had networking support, but neither can do UDP, so they were both quickly ruled out.

that left Java as the only other widely-installed cross-browser extension at my disposal. Java obviously has robust networking support, including UDP, so i headed down that path. the biggest problem now was that i have never created a Java applet, nor even written a line of Java code. but the syntax was familiar enough, and i was able to find some good sample code on the net that i was able to mash into a tiny applet that could send UDP packets. it actually worked brilliantly, and i was quite happy with myself for solving the problem so easily.

but of course, it was not that easy. there is that little restriction known as the 'same-origin policy'. running the applet on my localhost worked great, but as soon as i ran it from any other location, i would get a secuirty exception. i tried all kinds of combinations of values for the CODE and CODEBASE attributes, including file:// urls and even encoding the applet code as a data: uri, but i was thwarted at every turn (as so i should have been - the entire reason the restriction is in place is to prevent what i was trying to do). right before i gave up on the applet idea, i had the realization that if i could serve the applet up from the local host, then it would be able to communicate with the local host later. but configuring and installing a simple web server just to serve up an applet seemed like overkill. alas, the Java idea was a dead end.

so, it was back to the drawing board. what did the browser have access to that could bridge the gap? i decided to try a custom protocol handler, similar to the Itunes Music Store (itms://). a couple of simple registry entries and i had my growl:// protocol working. i had a helper process that sat in the background and everytime a growl:// url link was clicked, the browser would pass it off to my handler, along with the original url. i decided that i could pass any information as a JSON-encoded string in that url information. again, it worked great and seemed to be a good solution, but that made me sure that it must have a drawback. turns out the drawback in this case was that there was no way for the browser to know if the protocol handler was installed on the user's machine - if the protocol handler was installed, the browser passed it off nicely and all was good, but if the protocol was not installed, Firefox would present a dialog saying something like 'firefox doesnt know how to open the address because the protocol is not known' (IE and Safari both just returned a 404-type page). since i wanted websites to be able to use the communication feature if the user had Growl installed, but not mess up the experience if they didnt, this was a deal breaker.

i was starting to run out of ideas at this point, but i remembered the idea of serving up the Java applet locally. while i was pondering the details of that solution, i thought 'if i am going to have a local server to serve up the applet, why not skip the applet and just communicate with the local server?'. so i implemented a very simple webserver that runs when Growl is running that can be accessed at something like http://localhost:9889. the idea of using the url to pass JSON was repurposed and soon i was able to pass JSON-encoded Javascript objects to the local server, which code then parse the data and handle it in real application code. i couldnt use ajax to communicate with the local server (same-origin policy strikes again), so i decided to use the hidden iframe technique. i wrote a small js library to abstract everything out, so now you can write code in Javascript that almost mimics the code you would write if you included the Growl libraries in you application code:

PLAIN TEXT
JAVASCRIPT:
  1.  
  2. Growl.NotificationType someKindOfNotification = new Growl.NotificationType("some kind of notification", true);
  3. Growl.register("Website Name", [someKindOfNotification]);
  4. Growl.notify(someKindOfNotification, 'Notification from the web', 'this is the description', Growl.Priority.VeryLow, false);
  5.  

of course, receiving notifications from websites opens up the possiblity of spam and other noise, so applications that register from the web have their notifications disabled by default (thus requiring the user to explicity grant the notifications they wish to receive). but that is another topic for another day.

Ed: I decided to make today, "Extend the browser through APIs Day"

Ajax: Ajaxian

Location APIs: The Discussions

The Gears community is discussing a Geo Location API, which Aaron Boodman mentioned "was recently proposed to the W3C WebAPI group."

Aza Raskin just posted today about Geolocation in Firefox and Beyond which covers his thoughts on an API.

I thought it would be fun to look at the proposed APIs:

Gears Examples

PLAIN TEXT
JAVASCRIPT:
  1.  
  2. var geo = google.gears.factory.create('beta.geolocation');
  3.  
  4. // Get the position.
  5. geo.getCurrentPosition(function(position) {
  6.   updateMap(position.latitude, position.longitude);
  7. });
  8.  
  9. // Watch the position over time.
  10. var watchId = geo.watchPosition(function(position) {
  11.   updateMap(position.latitude, position.longitude, position.accuracy);
  12. });
  13.  
  14. geo.clearWatch(watchId);
  15.  
  16. // Only get the position if the last known position is more than a minute old.
  17. var now = new Date().getTime();
  18. var threshold = now - 60000;
  19.  
  20. if (geo.lastPosition &&
  21.     geo.lastPosition.timestamp.getTime()> threshold) {
  22.   updateMap2(geo.lastPosition);
  23. } else {
  24.   loc.getCurrentPosition(function(position) {
  25.     updateMap2(position);
  26.   });
  27. }
  28.  

Aza Examples

PLAIN TEXT
JAVASCRIPT:
  1.  
  2. var geolocator = new navigator.GeolocationRequest();
  3. geolocator.request(function(location) {
  4.   alert( location.latitude + ', '+ location.longitude + ", " + location.accuracy );
  5. });
  6.  
  7. var geolocator = new navigator.GeolocationRequest();
  8. geolocator.request({
  9.   success: function(location) { /* We've got the location! */ },
  10.   error: function(err){ /* There was an error getting location. */ },
  11.   accuracy: "neighborhood"
  12. });
  13.  

There is also a lot of talk around privacy and accuracy, and Apple has their own location manager too.

I hope that we can unify some of this, and give the browsers a geo location API soon. One simple JavaScript abstraction will enable a lot of great apps.

Ajax: Ajaxian

Taking Web Applications Offline, to the Desktop, and beyond

Ryan Stewart of Adobe and I got to give a joint talk this morning that covered Adobe AIR, Gears, and how you can build offline and desktop applications right now.

Obviously, Ryan gave an overview of AIR, and I did the same for Gears. We also discussed reasons to be excited about Web development, some of the ideas that are out there in the community, and how AIR and Gears can be seen as complementary.

We had some requests to put the slides online, so here they are below. I know it is hard to peruse slides without the talk over, but just think of it as a fun exercise to wonder what we said :)

If you are at Web 2.0 Expo, give me a shout on twitter.

Ajax: Ajaxian

Yahoo! BrowserPlus: Why wait for the news when you have strings?

After posting about Yahoo! BrowserPlus, we certainly have more questions than answers, and we could all wait a week or two to learn more.

But, where is the fun in that? Thanks to the fact that Open Source software often normally means that you will find a LICENSE.txt, and the binary itself will have information on what is used, you can sometimes glean information. Oh, and the UNIX strings command can help too ;)

So, armed with enough data to be dangerous (yet totally wrong) we see that:

  • The components seem to be called Corelets
  • There are distribution servers that can serve Corelets. The primary is set to browserplus.yahoo.com, but you could imagine anything.com too
  • There is the notion of "Dynamic Corelets" which leads you to believe that you can get new ones into the system, or that you can use dynamic languages to program the system.
  • OpenSSL is packaged and it appears that you use certificates to make sure the right code is run. It is unknown if you are given SSL primitives to work with, which would be fun
  • A native JSON implementation is bundled, which is probably just to parse the config file, and not exposed to developers
  • There is the notion of an "Upload Corelet" which could mean a way to upload new ones into the system, or a better file upload (please)

If you look in the installation directory, you also see the NSPR which tells us that the system uses the Netscape Portable Runtime:

The Netscape Portable Runtime, or NSPR, is a platform abstraction library that makes all operating systems it supports appear the same to Mozilla. NSPR provides platform independence for non-GUI operating system facilities. These facilities include threads, thread synchronization, normal file and network I/O, interval timing and calendar time, basic memory management (malloc and free) and shared library linking. A good portion of the library's purpose, and perhaps the primary purpose in the Gromit environment, is to provide the underpinnings of the Java VM, more or less mapping the sys layer that Sun defines for the porting of the Java VM to various platforms. NSPR does go beyond that requirement in some areas and since it is also the platform independent layer for most of the servers produced by Netscape. It is expected and preferred that existing code be restructured and perhaps even rewritten in order to use the NSPR API. It is not a goal to provide a platform for the porting into Netscape of externally developed code.

Ok, not back to just waiting for the real information. Again, it is great to see Yahoo! apparently thinking about how to make browsers do new tricks, which is why I am excited about Gears.

Ajax: Ajaxian

Yahoo! BrowserPlus: The rumour is true

Awhile back I heard a rumour that Yahoo! had a "Gears-like" project that was cancelled. I thought this was a shame, as having Yahoo! pushing the browser would be a great thing, and I wished that we could all join forces and push together.

It turns out the rumour is true, and even better, the project has survived. Skylar Woodward of Brickhouse talks a little about it on his blog:

After 3 years of hiding out in the campuses of Yahoo! it’s good to finally have something external to show for it. Most exciting is the release of BrowserPlus, a software and software distribution framework that allows device developers (desktop, mobile, etc.) to seamlessly bridge the browser programming environment (DHTML, JS) to any component they can dream up (VoIP, image manipulation, data caching, etc.). Some time ago we created a platform team to focus on device software at Yahoo! and this is what has emerged amidst the quickly shifting strategy of the mothership. The 1.0 release of BrowserPlus is intended only for use by Yahoo! sites to enhance customer experiences; however, in the coming months, developers might expect the ability to use components on their own sites.

In the meantime, you can hack the framework on your o