Slashdot Mirror

In the next 5 years people who think computing productivity has maxed are in for a surprise. There will be at least one toolkit that treats the Internet the way Qt or GTK treats. What the window metaphor did for a single computer's filesystem, this thing will do for the web, which is a filesystem, as you know. (Hint: I don't think it'll be Windows Genuine .NET.)

The problems are those of basic client-server programming--that is, figuring out the browser/http/server data-access patterns and optimizing the protocols, extending these protocols as new functionality is introduced, and ensuring that these protocols work across geo-distributed data centers when the speed of light becomes a factor. Designing applications with built-in redundancy so that they are resilient to abuse is also a challenge.

My favorite: "geo-distributed data centers when the speed of light becomes a factor" - that's a keeper from the Microsot dust-bin of bad apps (and bad writing).

Microsoft programmers seem to learn everything anew [and sadly, to create their own terminology for standards and terms already defined and accepted by standards groups].

They could have referenced what others had done, could have paid attention to the W3C groups and learned, like the rest of us did, about REpresentational State Transfer(REST) and the principles upon which the WWW was architected. But instead they usually recreate all such effort. Sad(Lucky?) thing is they're not finished yet; they still lag behind.

"Embrace & Extend" in execution becomes "Misunderstand & Misapply".

Indeed the parent is correct. AJAX violates the principles of REST that the WWW is based upon. for this reason alone AJAX is doomed to failure.

Wikipedia is (just!) a user interface through which "anyone can edit" most of the GFDL text corpus. However it has serious problems, most of them due to being

1. based on MediaWiki which is in turn based on MySQL only,
2. governed by morons
3. inventing its own wikitext standard day by day to deal with its format problems in dozens of languages.

The GFDL Text Corpus is a vast volume of over half a million articles that have received at least some well-intended editorial attention at Wikipedia and other MediaWiki based services like SourceWatch, Metaweb and Consumerium. (There are also non-GFDL MediaWiki services like Wikitravel which are not part of this corpus but part of the CC-by-sa text corpus, which can be handled on similar terms but not mixed with texts licensed under GFDL).

The fact that the GFDL corpus includes many articles on many topics in dozens of languages authored by thousands of users, much more diversity brought to much higher standards of uniformity than any other set of wikis, suggests that no wikitext standard dare be based on anything but the Wikipedia conventions.

As these settle down, it should be possible for a real standard to emerge, be supported as a MoinMoin parser, and suck the entire GFDL text corpus into PythonSpace, so that real coders can work on it RESTfully, using meaningful HTTP events that can do transactions that dig deeply into the text. Thus routing around bad governance and bad MediaWiki perl code and bad MySQL database.

Experiments in RESTful protocols would be drastically simplified by having a syntactically disciplined corpus all under a single license that was nonetheless representative of a vast range of topics and languages - and HTTP events could be defined that reflected wiki implementation features like the watchlist, with a high degree of certainty that it would work ALMOST as well as the existing ciontent managemeny features of only one wiki. Effectively, distributing management of the text corpus using a REST protocol, routing around Wikipedia itself, and permitting arbitrary text processing on the articles. Which thousands of people are editing and willing to edit. This is the ultimate test base for REST projects!

Wikipedia is (just!) a user interface through which "anyone can edit" most of the GFDL text corpus. However it has serious problems, most of them due to being

1. based on MediaWiki which is in turn based on MySQL only,
2. governed by morons
3. inventing its own wikitext standard day by day to deal with its format problems in dozens of languages.

The GFDL Text Corpus is a vast volume of over half a million articles that have received at least some well-intended editorial attention at Wikipedia and other MediaWiki based services like SourceWatch, Metaweb and Consumerium. (There are also non-GFDL MediaWiki services like Wikitravel which are not part of this corpus but part of the CC-by-sa text corpus, which can be handled on similar terms but not mixed with texts licensed under GFDL).

The fact that the GFDL corpus includes many articles on many topics in dozens of languages authored by thousands of users, much more diversity brought to much higher standards of uniformity than any other set of wikis, suggests that no wikitext standard dare be based on anything but the Wikipedia conventions.

As these settle down, it should be possible for a real standard to emerge, be supported as a MoinMoin parser, and suck the entire GFDL text corpus into PythonSpace, so that real coders can work on it RESTfully, using meaningful HTTP events that can do transactions that dig deeply into the text. Thus routing around bad governance and bad MediaWiki perl code and bad MySQL database.

Experiments in RESTful protocols would be drastically simplified by having a syntactically disciplined corpus all under a single license that was nonetheless representative of a vast range of topics and languages - and HTTP events could be defined that reflected wiki implementation features like the watchlist, with a high degree of certainty that it would work ALMOST as well as the existing ciontent managemeny features of only one wiki. Effectively, distributing management of the text corpus using a REST protocol, routing around Wikipedia itself, and permitting arbitrary text processing on the articles. Which thousands of people are editing and willing to edit. This is the ultimate test base for REST projects!

Wikipedia is (just!) a user interface through which "anyone can edit" most of the GFDL text corpus. However it has serious problems, most of them due to being

1. based on MediaWiki which is in turn based on MySQL only,
2. governed by morons
3. inventing its own wikitext standard day by day to deal with its format problems in dozens of languages.

The GFDL Text Corpus is a vast volume of over half a million articles that have received at least some well-intended editorial attention at Wikipedia and other MediaWiki based services like SourceWatch, Metaweb and Consumerium. (There are also non-GFDL MediaWiki services like Wikitravel which are not part of this corpus but part of the CC-by-sa text corpus, which can be handled on similar terms but not mixed with texts licensed under GFDL).

The fact that the GFDL corpus includes many articles on many topics in dozens of languages authored by thousands of users, much more diversity brought to much higher standards of uniformity than any other set of wikis, suggests that no wikitext standard dare be based on anything but the Wikipedia conventions.

As these settle down, it should be possible for a real standard to emerge, be supported as a MoinMoin parser, and suck the entire GFDL text corpus into PythonSpace, so that real coders can work on it RESTfully, using meaningful HTTP events that can do transactions that dig deeply into the text. Thus routing around bad governance and bad MediaWiki perl code and bad MySQL database.

Experiments in RESTful protocols would be drastically simplified by having a syntactically disciplined corpus all under a single license that was nonetheless representative of a vast range of topics and languages - and HTTP events could be defined that reflected wiki implementation features like the watchlist, with a high degree of certainty that it would work ALMOST as well as the existing ciontent managemeny features of only one wiki. Effectively, distributing management of the text corpus using a REST protocol, routing around Wikipedia itself, and permitting arbitrary text processing on the articles. Which thousands of people are editing and willing to edit. This is the ultimate test base for REST projects!

> I could not find an easy way to roll back the changes.
I've replaced the goatse links with the links from revision 21 (hoping that those were correct). That was revision 24, and now somebody made revision 25, in which another link was corrected.
AdvocayPlatforms should be safe for visting now.

The advocacydev wiki linked to in this article has been vandalised, and several links have been redirected to goatse.cx.

So be careful if you are browsing from work.

I could not find an easy way to roll back the changes.

64-40-63-15.nocharge.com seems to be the vandal. Go to Revision 21 if you want the non-vandalised site.

I think we don't need more between the voter and the politicians, we need less.

I'm concerned that it is just another centralized database of information. At least with Passport you don't have to worry about their database being bought by Microsoft.

At Identity Commons we intend to give people full control over their personal profile information, including not only who has access to which parts under what circumstances, but also where which parts of it are stored. If you don't trust any of the "banks" you can store it under your virtual mattress (if that's where you keep your server, though it might get kinda hot under there).

The free and open source code base is built upon two new OASIS XML standards, Extensible Resource Identifiers (XRI) which add (among other things) persistence and cross references to URIs, and the XRI Data Interchange (XDI) spec which enables a "dataweb", much like URIs enable a "document web". The coolest part of XDI is the concept of Link Contracts, that enable fine-grained access control over profile data while simultaneously recording the details that both parties agree to (and electronically sign) before any data exchange takes place.

While we're still a month (or more) from announcing, we have enjoyed some good initial exposure.

BTW: we're looking for people to play with the (pre-alpha) software (it's on SourceForge and there are even some CPAN modules) and help us bring it to the next level.