via http://twitter.com/programmingjoy/status/5857692995

I decided to re-engineer it from the ground up. JPolite V2 is then a complete re-design from the ground up with nothing from V1 except for the look & feel. The code structure is much clearer which makes it easier for customization, as well as integration with other jQuery plugins.

A new feature that is now being tested with JPolite is called XDO (XML Data Object), which currently supports JSON objects only. The whole idea is based on some discussion around “Thin Server Architecture” and REST architecture style, that a browser client first construct the foundation of a web app with STATIC content (HTML, CSS and JavaScript) from a web server, and then exchange only DATA (XML, JSON, TXT) with the application server, which relieves the server from the burden of generating HTML markup. This feature is still experimental with lots enhancements expected.

• Why REST Failed - "ERH complaining (rightfully) that browsers (and web presentation specs) should support PUT and DELETE out-of-the-box. I couldn't agree more. And yes, the title is unnecessarily inflammatory." | http://cafe.elharo.com/web/why-rest-failed/
• Carrot Vs Orange discusses the benefits, drawbacks, and arguments for or against Pie Api approaches "HTTP using GET/POST to a single URI" (Carrot) vs. "HTTP using the REST Architectural Style" (Orange or simply REST). http://intertwingly.net/wiki/pie/CarrotVsOrangeDiscuss

Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP(S) traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.

Fiddler is freeware and can debug traffic from virtually any application, including Internet Explorer, Mozilla Firefox, Opera, and thousands more.

An I thought the Fiddler name was a metaphor for the bow going back an forth like HTTP messages.

via http://itc.conversationsnetwork.org/shows/detail4073.html

Three sided-cloud

There are three sides to the cloud:

1. The authoring tool. I edit and update a feed. It contains a <cloud> element that says how a subscriber requests notification of updates.

2. The cloud. It is notified of an update by the authoring tool, and then in turn notifies all subscribers.

3. An aggregator. Subscribes to feeds that may or may not be part of a cloud.

What they call real-time 

via http://dashes.com/anil/2009/07/the-pushbutton-web-realtime-becomes-real.html via http://dashes.com/anil/2009/08/what-works-the-web-way-vs-the-wave-way.html

$('<ul><li><span class="library" /></li></ul>')
    .items([
        {library:'Prototype'},
        {library:'jQuery'},
        {library:'Dojo'},
        {library:'MooTools'}
    ])
    .chain();

Chain.js isn’t just bind data automatically to your HTML, but it also maintains and manages your data/items.

var data = {first:'Stephen', last:'Hawking'};
 
// Add one item
$('#persons').items('add', data);
 
// Remove item
$('#persons').items('remove', data);

via http://www.trilancer.com/jpolite2/

For me, the web is URIs, a standard set of verbs and a standardized EVAL function. The verbs are mostly GET and POST and the standardized EVAL function is the concept of a browser that can EVAL HTML and can eval JavaScript. I don't thing we can afford to leave JavaScript out of the top level definition of what the Web is because there is too much at stake.

There is a huge difference between a web of algorithms and a web of data. For computing eons, we have known that a combination of algorithms and data structures lead to programs. Less well known (outside computer science) are the problems of trying to build applications using one without the other or trying to fake one using the other.

Lisp, TeX, SGML...all of these evidence the struggle between declarative and imperative methods. Today, the problems are all the same but the buzzwords are different: JavaScript, XSLT, XML...

via http://bitworking.org/news/427/js-rest-and-empty-windows

There are actually 3 protocols and 2 APIs that are used in Wave:

• Federation (XMPP)
• The robot protocol (JSONRPC)
• The gadget API (OpenSocial)
• The wave embed API (Javascript)
• The client-server protocol (As defined by GWT)

The last one in that list is really nothing that needs to be, or will probably ever be documented, it is generated by GWT and when you build your own Wave client you will need to define how it talks to your Wave server. The rest of the protocols and APIs are based on existing technologies.

1. Use HTTP
2. Use your verbs
3. Keep Your URL/URIs Consistent
4. Use Your Status Codes
5. Expose (And Accept) Multiple Data Formats
6. Protect Your Users with OAuth
7. Don’t Shut Off HTTP Authentication Entirely
8. Document, Document, Document

Username:  	 joe.gregorio
Type the characters you see in the picture below.


Letters are not case-sensitive
Project ownership: 	feedvalidator
robaccia
mimeparse
httplib2
uri-templates
atompub-mulitpart-spec

google-app-engine-samples googleappengine gae-sqlite google-app-engine-codelab app-engine-tutorial Project membership: feedparser gdata-python-client doctype skia

"In REST, “post” is used for any action which results in a resource change or side-effect, and cannot be repeated without the change or side-effect happening again. An SQL “insert” operation would be implemented as a REST “post”, for example, but so would an SQL “update” which increments a value, or the sending of an email. A practical rule of thumb is that a “post” should be simple and quick, leaving the way for future changes using “put” as soon as possible. A CRUD “create” is a quite different thing. “Create” explicitly creates a new resource, and is undefined if that resource already exists."