Yet another virus is set to cause havok this Friday for Windows users.
Have you heard about the new Unix virus? It comes in source form. All you have to do is visit a website that hosts the virus, right-click and save the file to your hard drive, untar it to a temporary directory, run ./configure, make, make test, then su to root and run make install, then run the program. Poof – you’re infected.
The guys at Ajaxian have just announced The Ajax Experience, a three-day conference dedicated to all things Ajax to be held at the Westin St. Francis in San Francisco on May 10-12.
I’ve been invited to speak, so I’m builidng up a presentation and I’ll be there for the duration – look me up if you go. Be sure to sign up early, looks like it’s going to be a full house.
Informit has a very, well, informative article on the BSD family of Unix operating systems.
For over three years now, I have been using OpenBSD for its high security and powerful packet filtering. With a history dating back as far as 1978, BSD is incredibly stable and each branch of it gets more flexible with each release.
The BSD License is much less restrictive than the GPL (used by Linux), which makes BSD attractive to businesses.
On an Exchange server where I have an account, there is a public folder that receives alert messages. I want to collect all the messages in this folder, filter by subject, order by date, and extract text values out of the body of each message. I’d like the output to be delimited text so I can use other tools to perform further analysis, such as loading it into Excel and building a pivot table, or sorting and slicing with any number of tools. I’d like to be able to repeat this automatically.
I started by looking for script examples.
The first ones I found used VBScript under WSH to instantiate the CDO MAPI.Session object, create a Public Folders collection and iterate from there. There are a few different reasons I don’t want to use this approach:
The next solution I found used ADODB to query Exchange via the Exoledb datasource.
I thought I’d try loading up Outlook on my PC to have a look. It’s installed but I never use it (I use Outlook Express against my main POP3 and OWA against this server). I start up Outlook and go to Tools..Accounts, and select Exchange Server from the wizard.
After setting it up, I get into Outlook and navigate to the folder. I choose File..Export and try to export to Excel, to Text, to ANYTHING.
I have a colleague try from his Outlook and it’s useless because no matter how hard we tried:
Next, I decided to connect to the server with NNTP or IMAP or POP3.
Next, I tried to connect to the server’s M: drive which should be an ExIFS filesystem view of the Exchange store.
I tried to RDP into the server.
Ok, so ask me what I think of closed systems and protocols. Against any IMAP or NNTP server, I would have been done in 5 minutes with no dependencies.
I’ve spent a lot of time over the years playing with different methods of having a web page get data from the server without refreshing the page. One of my major criteria has been to find a method that works across all browsers. A few different methods have cropped up over time, following an evolutionary path.
In 1998, I used Microsoft Remote Scripting, which used a Java applet for its transport layer. Java later became a problem, since it’s blocked by firewalls and no longer automatically supported by all of the main browsers.
In 1999 I started experimenting with frames, then a hidden Iframe, which I used in my JSRS library in 2000. Iframes have become deprecated as of the XHTML specification, and browser history can be affected by their use, making this workable but suboptimal.
In 2000 I wrote RSLite which uses a client-side image object and a cookie. This works across pretty well all browsers but has limited value due to url and cookie length limits.
I started to use and promote Microsoft’s XMLHttp object fairly early on, but its limitation to IE and at that time only beta Mozilla made it not-ready-for-primetime. It has since come into its own in the form of Ajax, however there are still cross-domain scripting limitations, which are an impediment to the kind of Web 2.0 mashups that are some of the most compelling new uses of browser technology.
Danne Lundqvist was amongst the first to talk about the idea of using dynamically-generated script tags to send and receive data. In conjunction with Douglas Crockford‘s JSON JavaScript Object Notation, this method has recently been promoted by Yahoo in their Javascript Developer Center as a way to perform cross-domain data transmission.
Full coverage of the method can be seen on Dan Theurer‘s blog.
I am beginning to think that the combination of JSON and On-Demand-Javascript holds a great deal of promise:
It may be just another crayon in the box, but I think it’s going to get a lot of sharpening now that Yahoo is actively promoting JSON.
Well, not really three bears, but it makes a good title.
I’ve been thinking about the history of Web Application Development…
From my perspective, web UI development has traditionally been split into three camps:
(Hmmm… they all start with P. Maybe it should have been the three little pigs.)
Each of these camps has a set of requirements and a set of constraints. The constraints of one camp are often offset against the needs of another, causing compromises to have to be reached before an application can be built.
In the beginning, the Plumbing group formatted data into html designed by the Presentation folks and passed it to the browser. Browser interaction was limited to basic population and submission of form elements, much to the chagrin of the Presentation and Process folks.
Porridge 1.0. Yum yum, ho hum.
Along came early (pre-DOM) DHTML. Once the page was rendered, layers could be moved, resized, hidden and displayed. Layer content was difficult-to-impossible to change once rendered. Javascript allowed some form content manipulation. The Presentation people could do some nice animation and acrobatics, but the Process group was left with the constraint that in order to advance through their flow models, it was necessary to refresh the page.
This porridge was too gloopy and didn’t flow nicely.
Some Remote Procedure Call (RPC) capability was introduced in the form of Remote Scripting. This allowed the Presentation group to interact with the Plumbing group to get information from the server and remove the page-refresh constraint from a data perspective, but they still didn’t have enough control of re-rendering the page in place to do much without forcing a visit to the server to rebuild a new page. This caused the Process folks to have to change their single-page flow designs to stretch over multiple wizard-style pages, a necessary but bletcherous compromise.
This porridge was better but still a bit lumpy.
Once DOM-based browsers came along, the elements were in place to satisfy the Presentation group (full manipulation of the rendered page) and the Process group (RPC + UI control). The plumbing guys weren’t happy though, because Remote Scripting either required a client-side Java applet, a non-standard XMLHTTP ActiveX object, or some acrobatic cross-browser hacks using iframes or cookies.
Many people started to build very useful apps based on these elements. These were the people who decided they could live with a browser-specific implementation. Many enterprise apps fell into this scenario, but not many public applications.
This porridge was fairly tasty and getting warm but didn’t have full confidence among the groups.
When IE built XMLHTTP into IE (rather than as an external control) and Mozilla baked its XMLHTTP implementation into its browser, the time was ripe. It wasn’t long until development groups started building rich applications that used it all together.
When Jesse came along and gave it all a name, everyone decided this porridge was ready for eating.
Now we have a zillion flavours of porridge.
With Ajax, the Process, Plumbing and Presentation groups are able to work together with much less friction. Each group’s needs can be met while imposing less constraints on the other groups than before. Many rich applications are being developed which serve as testament to this new ability for the three groups to interact smoothly.
I think some of the most significant advances we will continue to see from here are in the building of abstraction layers that allow modular building of highly interactive apps. The marshaling of complex object data from client to server and back via various serlialization techniques (XML, JSON, etc) has been by and large limited to corporate intranet applications due to performance considerations. With demonstrated tools and techniques that overcome these concerns, newly unified multi-dimensional development groups are already starting to make some very compelling apps that are spilling out of the intranet into the wider Web.
I think weather.com needs to rethink their popup ad campaign strategy this week.
Robert Scoble tells a story about running into Aaron Boodman:
Then Nick introduced us and said “he wrote Greasemonkey.” I answered “I’m not worthy.”
This reminded me of the time I first met Aaron, at the dinner thrown by Adaptive Path and O’Reilly at the end of the first day of their Ajax Summit back in May. I saw him across the room and went over to say hello, since we had had some online interaction in Remote Scripting circles some years ago.
Later, after having dinner seated beside Brendan Eich, creator of the Javascript language and Chief Architect at Mozilla, I saw Aaron coming our way and took the opportunity to introduce the two of them. “Aaron, this is Brendan Eich; Brendan, this is Aaron Boodman”. They reach across me to shake hands, and Brendan says “Wow, Hi Aaron, I love your work!”.
Humble as they come, Aaron was dumbstruck. He managed to stammer “…I think you have that the wrong way around!”, and then they fell into a rich conversation and I slipped away to mingle.
You are currently browsing the brentashley weblog archives.