Slashdot Mirror

You have no idea how much server-side GZipping futzes up AJAX and Flash apps in IE. Absolutely no idea.

From the company website:

• "tools for gathering and aggregating information from throughout the open source community. "
• "Sash Open Source MiddleWare"
• "the service-quality leader of enterprise support and maintenance for Open Source infrastructure software."
• "Continuous Support System, providing unprecedented timeliness and effectiveness for enterprise software."

http://www.sourcelabs.com/

Indeed. You can find a little more information on their website. Because putting a link to the company in the article summary would just make things too easy for people, right?

Maybe it was that RMS was hiding his RFID tag in 'tin foil', and so they just couldn't find him...

Soko

(All quotes from Bruce Perens' blog, http://perens.sourcelabs.com/)

You can't give Richard a visible RF ID strip without expecting him to protest. Richard acquired an entire roll of aluminum foil and wore his foil-shielded pass prominently. He willingly unwrapped it to go through any of the visible check-points, he simply objected to the potential that people might be reading the RF ID without his knowledge and tracking him around the grounds. This, again, is a legitimate gripe, handled with Richard's usual highly-visible, guile-less and absolutely un-subtle style of non-violent protest.

I'm not quite sure I understand why RMS felt that the RFID was a violation of his privacy. It's a SECURITY BADGE. It's whole PURPOSE is to identify the wearer. If he didn't want to wear it, then he shouldn't have attended the event.

I disagree that it's a "legitimate gripe." Remember, he wasn't out on a public road somewhere, but in a "what I suspect is) a secure facility. Furthermore, if somebody really DID want to track him, they would just have somebody watch him the entire time. Believing that somebody wants to track your every motion is either a sign of paranoia or an overinflated sense of self-importance.

All of this completely disrupted the panel that was supposed to follow ours in that room, and the folks operating that panel were rightly furious... ..So, this was no doubt an interesting problem for the security folks, who had no real idea who Richard was except that he was someone reasonably distinguished who was visibly violating their security measure.

So he makes his point and disrupts the schedule of other panels. Great--this leaves the impression that "Others be damned, I'll make my point however I damn well please." That will earn you a lot of respect. And before you point out that it was the UNU security personnel who caused the ruckus and not Stallman, re-read the account. He was VIOLATING A SECURITY MEASURE. What do you expect them to do? He's violating a security measure that they are there to enforce.

I didn't see anyone further molesting Richard, but I'd imagine he was followed around by plainclothes agents for the rest of the day. This, however, may not be unusual. Perhaps Kramer even got his own protective detail.

See above.

I could just be ignorant of RFID, or misinterpreting Stallman's point of view, but he does seem to be a bit "over the top" in terms of making his opinion known to the public at large. He's 100% entitled to his opinion, but there is a point where making one's point and the cacophony that comes with it washes over the actual issue at hand. What will be remembered more, the RFID issue or that Stallman caused a commotion at a UN event?

Bruce Perens is working on model security for Active Record sponsored by Soucelabs

They are used in very specific circumstances in regular application email. it's called "opening the email". sounds alot like what this web app does.

This is blatently incorrect. Most regular email apps "open the email" when you click on it. i.e. The email is shown in a preview pane. Double-clicking has a very different effect of opening the email in a new window. Since this program does not open the email in a new window when double-clicked, its implementation is wrong.

And to define wrong, I mean: inconsistent with the rest of the applications and unintuitive to a new user. "Wrong" may also be construed to mean a failure to meet HCI guidelines. The seventh guideline from this page, for example, states that you should not, "Invent new UI conventions [for AJAX applications]."

Open Source is NOT always the only answer, some people have to make a living.

Agility, Service-Orientation, Enterprise Architecture, and Software Development

State of Ajax: Progress, Challenges, and Implications for SOAs

A lot of bits have been pushed around the blogosphere on the topic of Ajax over the last few months. This includes my own post back in March, which gave a general overview of what Ajax was and what it does. A lot of exciting stuff has happened since then, and Ajax has rapidy matured into a development of major significance. Coverage has been all over the map and runs the gamut from Rasmus' been-there-done-that 30 second Ajax tutorial to Alex Bosworth's list of Ajax Mistakes to the uber-repository of Ajax knowedge, Ajax Matters.

Many of you already know that Ajax is a web client programming style which eschews traditional HTML web pages, which are only sprinkled lightly with JavaScript and reload pretty much every time they are updated or clicked on. Instead, an Ajax web client receives an Ajax JavaScript library into a hidden frame which provides run-time visuals on the main browser window that look and feel very much like a native application. Ajax web clients, once loaded, communicate with XML services on the back end (via a browser's built-in powerful XMLHttpRequest API), and then use JavaScript to manipulate what the users sees programmatically via DHTML.

All of this allows Ajax to provide a compelling user experience because 1) it doesn't reload the web page, and 2) it runs asynchronously allowing background server-side requests for information to be issued, all while the users clicks, types, and otherwise interacts with the application in the foreground. Google Maps is the pre-eminent example of a modern Ajax application: rich, interactive, easy-to-use, and predictive in that it loads the map tiles that are just offscreen in case you need them. This is all very good for web client client development, but why all the attention across the board?

Figure 1: Ajax: The first compelling new client application model since the modern web browser

Because Ajax is a sincerely compelling synthesis of the ubiquitous features found in the most popular Internet browsers is why. Practitioners of Ajax get high-intensity user interaction (end-user productivity), asynchronicity (efficient backround processing), web browser access to web services (web service access, reuse, and interoperability, as well as SOA integration), platform neutrality (browser and operating system agnosticity), and the Ajax feature set can be delivered as a framework you don't have to create yourself (developer productivity).

Individually, these items are very nice, but taken as a whole, working solution and you have something extremely special. While many folks thought the web browser story had stopped around the year 2000, Ajax takes us to a whole new place. Slashdot recently highlighted a notable new article in Wired that claims that the industry, mostly on the basis of Ajax, "has affirmed the viability of the web as a standalone software development platform."

This is no small thing, and has the potential to repave the modern application development landscape. Why? Because Ajax creates a rich and fertile new space for developing software solutions that can reach almost anyone, anywhere whatev

Can never have too many toolbars: http://www.raspberryheaven.net/~shut/spyware.jpg

- Alex Bosworth

There are at least some out there that would say the article is heavily biased. Not that these responses aren't.

Me? I like RSS 2.0. It's simple (for what is does), and extensible (for most of what it doesn't). To each their own.

What with the assimilation of Daniel Robbins' Gentoo "I'm helping Microsoft to understand Open Source and community-based projects." and the hiring of Bruce Perens at a marketing firm, who will carry the F/OSS flag for the little guys? I look to RMS and ESR to maintain their positons of power and be the bastions of hope for me as a contributing developer to various F/OSS projects. We are losing our focus as a group and need a strong leader to rally around during these turmultuos times.

AJAX is great and all, but it is going to turn in to the next Flash, being misused and abused by anyone and everyone. Alex Bosworth wrote an article a few days ago regarding the dangers of AJAX. The article can be found here. I agree with several of his points including problems with linking and the back button.

Google did a great job using this technology, I have seen many others fail. Just cause it's there to use, doesn't mean it should be used.

Just today I was looking at this page It's a list of ten easy to do mistakes in Ajax apps. Some of them are not that easy to avoid...

There is a need to standardize (as much as possible) the way that AJAX will work in the browser. There are a lot of code-writers and code-copy-n-pasters out there. When you visit one of these sites, you know because the browser may act funny due to poor programming/hacking of Javascript interacting with the server. AJAX is much bigger than just XML messaging, it's an opportunity to bring a more traditional application model to the browser via Event handling and dispatching. Notice that if you have an engine or framework that is well built, it's quite simple to add event handlers like key presses or mouse clicks or even drag-n-drop. If one was to script each element on a page, that gets heavy and can slow the browser. Which - btw, is why AJAX hadn't caught on until recently: computing resources were not sufficient in many cases.

That being said, everyone should look at http://www.sourcelabs.com/ajb/AJAX Mistakes. There's also a nice list being compiled at http://www.openajax.net/OpenAJAX .net. This combination of technologies has been around for a while, however, as people find them more useful and interesting, there is a need for good information and a solid foundation for folks to work off of.

We think there is an opportunity to make a very significant business in open source software, and also to fundamentally disrupt the cozy status quo of proprietary software. Customers of all shapes and sizes are fed up with being locked-in to proprietary API that force them to ransom their applications back from aggressive sales people year after year. Licenses for infrastructure software (databases, middleware etc.) were worth more than $14 Billion last year. The companies riding that gravy train are not going to cede that revenue without a fight. To win this battle, the open source community is going to have to do things differently, and that doesn't mean adopting the Windows playbook or locking the customer into a cradle-to-grave services embrace. We think a new approach is required, and while we're just getting started, you can read more about our plans at http://www.sourcelabs.com/plan.htm. In a nutshell, we don't think customers should have to submit to being locked-in to software vendors' business models to get the dependability, convenience and support they need to run their software. And we think that a lot of customers will pay to set themselves free. Yeah, I work for SourceLabs. Maybe you can too http://www.sourcelabs.com/jobs.htm

We think there is an opportunity to make a very significant business in open source software, and also to fundamentally disrupt the cozy status quo of proprietary software. Customers of all shapes and sizes are fed up with being locked-in to proprietary API that force them to ransom their applications back from aggressive sales people year after year. Licenses for infrastructure software (databases, middleware etc.) were worth more than $14 Billion last year. The companies riding that gravy train are not going to cede that revenue without a fight. To win this battle, the open source community is going to have to do things differently, and that doesn't mean adopting the Windows playbook or locking the customer into a cradle-to-grave services embrace. We think a new approach is required, and while we're just getting started, you can read more about our plans at http://www.sourcelabs.com/plan.htm. In a nutshell, we don't think customers should have to submit to being locked-in to software vendors' business models to get the dependability, convenience and support they need to run their software. And we think that a lot of customers will pay to set themselves free. Yeah, I work for SourceLabs. Maybe you can too http://www.sourcelabs.com/jobs.htm