brentashley

There’s a bit of a hooplah going on about modifying or deleting a blog entry or comment after it has been posted.

Scoble weighs in with his personal policy on the matter.

I often delete comments due to spam content, but never due to a difference of opinion. I suppose the main reason I might *want* to delete or modify something on my blog is because I’ve said something that I regret, and yet, I make it a policy not to.

For instance, I was somewhat snippy with a commenter recently. I dropped the f-bomb as I am sometimes wont to do, and I rather wish I hadn’t, however it was said and I don’t think it’s fair for me to a) unsay it, or b) change its tone after the fact.

If I really felt it necessary to mitigate every f-bomb on my blog, I’d go back and connect each one of them to their contributing factors – I’m pretty sure this particular one had some vintage inspiration.

I had an email conversation with a blogger recently who had disagreed with me (conversation via email because comments were broken). I pointed out how I believed he had misread me and his response was to remove his original post. I hope that once his comments are working again he reinstates it with my comment and his response to that.

Blogging can keep a history of discussions and not only their outcome but the mistakes we make along the way to finding the truth. It’s of benefit to those who follow to see the whole path, not just the end point.

Jesse’s Ajax article has certainly got a lot of discussion going, ranging from ho-hum to hyperbole.

A few pundits are postulating (or at least sensationalizing) that this could be the end of app dev as we know it, a new order storming the beaches, sweeping fat and smart clients out to sea. I have to think that Mary Jo Foley has tongue firmly in cheek when she says:

Will we see a dev world divided along Ajax/smart client lines? Or is there room for both programming platforms to coexist and (shudder) maybe even interoperate?

Perhaps she’s mocking the Wall Street Journal (no link, you gotta pay for it now) where it was suggested that Ajax may trigger a sea change in app dev.

Scoble joins the fray, while Joseph Cooney leans closer to my view which is that we should all add Ajax to our bag o’ tricks and pull it out only where appropriate.

I once introduced a junior programmer to Remote Scripting and soon found that every page he built was full of complex RPC-over-http interaction even to post a simple form. Let’s not all go there.

I wrote Blogchat in Feb 2002 and it’s still going. It’s one of the earlier examples of a completely javascript/html chat application without page refresh. It was specifically written without XML to keep the packets light since it polls.

Tim Aiello and I will try to hang around in the main chat there for a while if you want to drop by to see how it works.

Buzz buzz buzz.

It reminds me of the Big Honey Hunt where following a single buzzing bee turned into a roundabout adventure that never quite seemed to get to the source but ended up stirring up the entire bee community.

My sentiments match those of Dougal who is simply glad enough that developers have discovered these concepts, however late in the game and by whatever name (mind you, I’m fully behind Dougal’s ARSE …umm, strike that).

So it’s time to cut through the crap and get some work done with this stuff.

AJAX is an acronym for Asynchronous JAvascript + XML. Ok, now that I’ve told you that, forget you ever heard it. Ajax (proper case) has already come to represent a wider concept. The concept is this: Load up and render a webpage, then remain at that page while scripted routines make background trips to the server for data that is used to update the page in place by re-rendering and or hiding/unhiding portions of the page.

Now that we’ve got that settled, let’s break the concept down into some functional parts to see where the convoluted discussion’s apples and oranges lie:

• Presentation
• Invocation
• Message Encoding
• Transport

The Presentation layer manipulates the display of data using whatever technology is available. DOM manipulation is the current way to do it, but older methods used the various flavours of DHTML available from the browsers at the time. Keeping up with the current set of browsers and their rendering quirks is pretty hairy.

Invocation can be object oriented or procedural depending on the API wrapped around the transport. Asynchronous or synchronous invocation depends more on the transport implementation. My JSRS library for instance only offers asynchronous communication – a limitation imposed on it by the transport layer I needed to use to work across the different browsers available at the time. Microsoft’s Java Applet based Remote Scripting could do both sync and async, and provided both an object and a procedural interface. The XMLHTTP transport offers both async and sync and you can wrap it up how you like.

I prefer to remain lightweight in my message encoding, sending strings back and forth, perhaps encoding structures into Javascript code, a trick I first saw in Microsoft’s RS (the “uneval” function that serializes a javascript obect into the code to reconstitute it). You can get some quite efficiently sized packets with low overhead. Many people prefer to use XML either because their particular development space is all about XML or in order to raise the level of abstraction at the cost of API internal complexity. XMLHTTP etc is then used for the encoding/decoding.

There are various transport methods that allow a browser to send and receive data without page refresh. The lightest one I use is to create an image object and set its source url to a server-side script that takes the querystring parameters, performs work, and returns a string via a cookie, then sends an empty document as the image. Before XMLHTTP was widely available, various hidden iframe and layer methods were used in order to actually hack functionality out of browsers that had not been designed with arbitrary data transport in mind. Other methods involve returning Javascript to the browser for execution. I use XMLHTTP now because I can use it synchronously, which was not possible in Javascript alone because of the lack of a non-blocking sleep function (you go into a tight loop to wait for a result and CPU runs to 100%). Previously would need Java or Flash or an ActiveX control to get that level of control. Now the prominent browsers have their own versions of XMLHTTP with which you can get arbitrary data in either sync or async fashion.

It should be apparent by now that we’re talking about a concept that has remained constant since as early as 1998 and a set of techniques with which to accomplish the task which have evolved over time around the capabilities of the tools at hand. The method used for any project has been selected as a result of the project’s choice of platform and design parameters.

When I get a chance, I’ll try to compile a list of links. In the meantime, use your favourite search engine to look for “Remote Scripting” for some of the historical solutions, and “Ajax” for some of the new stuff.

Scott Rosenberg sums up all my thoughts about the Terry Schiavo case. If Dubya manages to step in despite years of due process, he might as well declare himself American Monarch and Defender of the Faith while he’s at it.

I finally did get an email from Groove on Feb 8th, a week after my last email sent to them. It was from the support center manager, who was able to push the right buttons in their organization to get me fixed up to my satisfaction on the 10th. No excuses, just solution, and not one that imposed a lot of effort on me.

From what I understand there is quite a large backlog. That backlog gave me two weeks and a lot of motive to evaluate other solutions. I’ve not yet determined my long-term outcome, but I’m glad to say I’m not as critically worried right now.

Again I’m waiting days with no response from Groove’s support folks.

Sorry, can’t do business like this. I’m not expecting them to jump through hoops for me, responding to my emails even to tell me to go away is better than no contact at all.

I’m not looking forward to moving all my data out of Groove to something else, but I can’t see another solution under the circumstances.

If you have ever used Groove, you will know that it regularly pops up a notification that there is some new version of a widget or installation helper. You click ok and it grabs it and installs it into your Groove client.

I got one of those notifications last Monday (a week ago today). As is normal, I clicked ok on it, however this time it downloaded a much larger package than usual. It wasn’t until the package finished and required a reboot that it finally came up and told me that I had upgraded from my paid version 2.5 (paid at 2.1 but upgraded to 2.5) to version 3.0, and that I had to either enter a valid 3.0 key or accept that I would now be limited to 3 spaces (I have 5 active spaces) and that various essential features would start to disappear over the next month (file replication for instance) unless I converted my new “Trial” software to a full license.

No problem, thought I, I’ll just contact Groove and have them right this for me, tell me how to downgrade and still use my data.

I consulted their site to get support. I have a login, but I could not find any indication how to actually get support. See if you can tell how to get support for a problem like mine (without paying) from this page: http://www.groove.net/index.cfm/pagename/SupportOptions/

Finally, I used the problem reporting link that I managed to get to from Groove’s help menu and submitted my query from an online form.

After 24 hours with no reply, I sent an email to support@groove.net.

After 24 further hours with no reply, I sent an email to sales@groove.net.

On each of the emails I stressed that I had yet to even receive an acknowledgement of my contact with them.

It has now been a week and I have still yet to hear from them. Not a sausage.

Here is a quote from their support page:

Outstanding customer care is yet another way that we seek to gain your trust in us as a company that can meet your needs. Our support team excels at resolving your issues quickly. Every inquiry is tracked and managed so we can resolve your issues effectively.

I see no evidence of any of the above assertions.

Groove has been a great tool for me, but I’m now looking for alternatives. I can’t consider it a critical tool in my business with service like this. Could you?

What’s up, Ray? I’ve never had any reason to be disappointed till now.

Update
90 minutes after my blog entry, a support message arrived (does someone have an rss search feed that takes higher priority than their email?) detailing how I can uninstall version 3.0, reinstall 2.5 and then restore from an archive.

Being that my last Groove backup is part of a drive image backup, this would entail at minimum a day’s work that could have been avoided had I been presented with a dialog box that clearly said “You are about to upgrade to version 3.0 – Are You Sure?”

I really had consciously decided not to upgrade to version 3.0 until I was ready to and would have declined the offer had it been clear to me.

Clearly, the simplest way out would be for me to pay the $25 or $50 to upgrade (oops – just looked it up. It’ll be $150 to upgrade to the professional edition. not sure what the filesharing edition does but I’d likely lose functionality from 2.5 Standard). I might well have done that a month from now, but I can’t imagine myself doing so with my back against the wall. I suppose that’s stubborn of me but I think I have a point.