next »

[EpicCyndaquil]

https://jetpack.mozillalabs.com/index.html

If I understand this correctly, we can use this to build add-ons for Firefox much like we would code a website? That's pretty interesting.

[thefluffball]

It's been open for quite a while hasn't it? Surely, using Javascript and XML (with bits of html sometimes) is close enough to web programming languages to make an add-on.

[darrenbeige]

The concept makes sense. I particularly like the ease of use of the input manipulation, and I am so glad they ran with the jQuery library. It's such a joy to use.

[inp o҉rtb]

Somebody disagrees.

[darrenbeige]

On those points, I agree with antimatter. The things he mentions should have really been the things that get into the HTML5 specification. A user doesn't care whether the browser knows this area is a <header> and that this is the <footer>, a user wants a functional, working browser that benefits himself/herself. The persistant tabs idea is very good I think, and is similar to the philosophy employed in Wave, with the little-to-no distinction being shown between robots and human participants.

[antimatter15]

Actually, one thing I think is a major design flaw that really sucks is that there's tons of distinction between a robot and a normal use at the API/Protocol level. Robots are entirely event based (there are time events, which sort of alleviate it by having the wave server periodically send out a pseudo-event). Robots lack certain abilities, can't actually use wave, they have to be invited by a user, etc. I feel Google only made the Robots that way so it could be used with appengine.

I think a better executed version of Jetpack would be the actual Chrome extension system. It takes many cues from Jetpack, including the embedding of a web page for addons/sidebars but has a more accutely permission-based system (while I don't exactly like what it does, forcing the developer to create a manifest of what it can do, rather than asking when the app wants the ability).

[darrenbeige]

Actually, one thing I think is a major design flaw that really sucks is that there's tons of distinction between a robot and a normal use at the API/Protocol level. Robots are entirely event based (there are time events, which sort of alleviate it by having the wave server periodically send out a pseudo-event). Robots lack certain abilities, can't actually use wave, they have to be invited by a user, etc. I feel Google only made the Robots that way so it could be used with appengine.

Robots will eventually be able to power off without having to react to an event, says Google. Your other point about not being able to let robots invite themselves, I think is fine though. You want users to pick to add functionality. If a robot automatically added itself to a Wave, I reckon many users would complain that Wave is suddenly doing something it doesn't normally do.

[antimatter15]

Well, Google is working on an Active Site API. But still having an API level difference between users and robots is stupid.

Not to mention the flaws of the Robots implementation. Right now, OT is not performed with robots. That means that for EVERY SINGLE KEY STROKE IN WAVE, Google has to send out a MASSIVE JSON POST request to the server with lots of metadata and the entire contents of the content now and the content to be added.

This reduces computation on the server, and with bots on App Engine, the latency for Google is minimal. But for external providers, the flaws are really evident.

[darrenbeige]

Not to mention the flaws of the Robots implementation. Right now, OT is not performed with robots. That means that for EVERY SINGLE KEY STROKE IN WAVE, Google has to send out a MASSIVE JSON POST request to the server with lots of metadata and the entire contents of the content now and the content to be added.

This reduces computation on the server, and with bots on App Engine, the latency for Google is minimal. But for external providers, the flaws are really evident.

I've always wondered how robots are gonna cope outside of AppEngine. My idea was to store in the Wave metadata an array of regexps. array('Bot1' => '(.*)', 'Bot2' => ' ([A-Z]{0, 3}) ') for instance. Then, the JSON POST is only made if a robot needs it. Otherwise, no POST to the bot is made. The array could be stored in the Wave when the robot is added (data in profile code), and if no such regexp is present, default to (.*) OR normal behaviour.

[inp o҉rtb]

Hm... use GAE to deal with the massively multiplayer online junk (MMOJ) and tease out the useful bits to send to your actual bot?

I just dumped GAE, btw. The lack of fulltext and other search options is ridiculous given the company's reputation. Now I'm running on CherryPy and Xapian.

[darrenbeige]

I just dumped GAE, btw. The lack of fulltext and other search options is ridiculous given the company's reputation.

Currently, Wave doesn't allow for non-App Engine robots, but I think the lack of better search facilities is poor. I mean its Google. They provide half-second updates to the search Inbox in Wave, but can't let you search the datastore properly.

[inp o҉rtb]

Hence, Xapian (or Lucene if you prefer Java). I'm just getting the basics down, and so far it's pwning MySQL at search and scalability. I figured I'd use MySQL or SQLite for storage and Xapian for search.

Google needs to expose some of the bigtable magic ;p