XML

Web 2.0? Or Web 2.0?

Don MacVittie — Tue, 25 Sep 2007 23:52:57 GMT

As you've no doubt noticed, there is a bit of duplicate name confusion in the Web 2.0 world. Developers say "Web 2.0" and they mean SOA, dynamic binding, etc. When business people say "Web 2.0" they mean blogs, video, RSS feeds.

DevCentral is an example of Web 2.0, the business version. We've got blogs, video (no DRM, thank you), podcasts, forums, articles, and it's all wrapped together nice as pie.

But DevCentral is also an example of utilizing Web 2.0. Some of the wizardry done behind the scenes and added to by the team is pure Web 2.0 nirvana.

So we get a lot of press about the end-user or business person version of Web 2.0, Jeff and John McAdam have talked about with the press about it repeatedly, people point to DevCentral as the definition of vendor-sponsored community, the list goes on.

The flip side of this is that not much is talked about Web 2.0 from a development perspective. DevCentral is a good example of that, and our ADN (Application Delivery Network) technology is a cornerstone of Web 2.0 networks. Lori is helping people understand the issues in her blog, and we're adding more and more Web 2.0 content all of the time.

That gives you yet another reason to hang out on DevCentral, the Web 2.0 Networking site - because it is both, Web 2.0 and Web 2.0.

Now if only we could get someone to use more intelligent naming - Like Web 2.0 and Development 2.0 or something - so that we're all a little less confused about what, exactly, we're talking about.

Don.

Technorati Tags: Web 2.0, SOA, Application Development

Drinking: Water, coffee, Moutain Dew (seriously, all sitting around my laptop right now).

Reading: Flames of War 2.0 (link is very slow - they don't have a genius like Joe keeping their DNN installation performing)

/TAG: Close of Tagging

Don MacVittie — Thu, 30 Aug 2007 20:48:38 GMT

Now that Lori has made my point - that people can't be trusted to correctly tag - we can move on to the other issues with all metadata.

Metadata is never a constant, and that is a problem for non-automated systems (and even automated systems). What tags you apply changes over time, and the list of tags grows - no matter what you do to curb tag explosion. And you have to have systems that use tagging in a coordinated way. Inevitably, some large company will claim "market differentiation" by creating their own special tagging scheme that starts every tag with "ms-". Then what?

That doesn't even touch on the data space required to store tag relationships. Want a wonderful world where all synonyms and translations of a word are utilized and correlated correctly? Yeah, that's maintenance nightmare compounded by an infinite and growing storage problem.

Google Ads are proof that the technology isn't there yet. Check any forum about this topic, and you'll find people with completely inappropriate ads being posted to their forum or blog because one post had one similar-use word in it... Because the technology isn't there.

So when they sell you on "Tag Clouds" and a unified world where your searches have more meaning, view it with a grain of salt. We have to get there eventually, but today is not someday, today is another day that they tell you "to get to Nirvana you must first tag 1000 documents".

Don't bite. Let the systems figure it out, then we can all complain about how inefficient the systems are - even though they'll be much better than people because a purpose-built system doesn't have anything better to do.

The point of my post was simple - people are not Tag Generation Engines. They're not even a very efficient stop-gap. And we don't yet have a qualified set of requirements for what should be done, just a drive that it must be. Run your IT shop with common sense, there's a lot more that needs doing that is important, so go do it. Save tagging for the aggregators, or better yet for the as-yet-uninvented Automagical Tagging Engine.

And Lori's analysis doesn't change that.

Don.

XML Tagging: A Broken Proposition

Don MacVittie — Wed, 29 Aug 2007 20:48:00 GMT

Lori and I were taking a break and talking about a recent tagging problem we had on DevCentral, and I finally had enough. She's Mrs. Web 2.0/3.0, and is happy to talk about tagging saving the world. I'm more realistic. Tagging is user-applied meta-data. It doesn't take a genius to see how well that has worked in Doc Management, ECM, or Disk-based meta-data. The users who follow the guidelines do fine, the ones who don't ruin the system. We can't make it work in most organizations, and now people are all googly over making it work for the entire world? Give me a break.

The real solution here must be automated in order for it to have any chance of working. Lori has a great idea for F5 customers to automate this process, but that doesn't resolve the issue for all of Web 2.0 unless we're going to grow even faster than the analysts think. Lots faster. Since the solution needs to be automated anyway, the correct solution is to bypass mandatory tagging and implement better search engines. Google (and others) are of course working on just that, so all will resolve itself. My concern is that in the interim a whole bunch of us will waste a whole bunch of time building taxonomies that are ever-changing and never-complete. Then we won't need them because the problem will be solved from another angle.

My take? Skip tagging - what do you use it for that can't be done with your search engine already? Spend your time getting productive work done, and let search engines and aggregators figure out the best way to classify documents based on what they are, not based upon what someone says (or does not say) they are.

Just a thought. When you know something hasn't worked in other fields, and the reasons are reasonable and easily quantifiable, applying those same processes to your field and expecting different results is not exactly wisdom.

Don.

Imbibing: Mt. Dew

Reading: Not reading, writing a book for TLG/Tri-G with my reading time

Blackberry, meet BigIP

Don MacVittie — Mon, 09 Apr 2007 18:07:10 GMT

I've been awfully quiet the last couple of weeks, locked away tracking down the options and testing out some theories on using iControl with the Blackberry.

I'm now to the point where I'm willing to talk about what I found and how I've settled on it, not yet to the point where it's anywhere near a complete deliverable.

The goal was simple - give a management interface to admins through their Blackberry. The problem is that Blackberry has seriously muddied the water about Java development for enterprise-class products. Just a few of the issues - their "enterprise class" solution (MDS) is to put a web server between the user and their application that proxies requests from the Blackberry and serves up responses. That would be fine if you had the time and inclination to configure a separate webserver. We felt that was too much to ask - easy enough in my test environment, not a viable option in most enterprises.

So after toying with that option we played with the Blackberry JDE and the Sun JDE. The Blackberry JDE was short some functionality, and the Sun JDE can't generate .COD files. So I could get both to work partially, but neither to do the job.

Then I took a look at kSOAP2 - a project that offers lightweight SOAP support for Java - aimed at MIDP-based devices. I had played with kSOAP, and it wasn't very good - poorly documented and error prone. kSOAP2 is better, though it's still tough to play with, at least most of its issues are documentation.

At this point the "System Information" page is completed, and the network statistics page is well on its way. The final configuration of the development environment includes the following class libraries:
kSOAP
kObjects
kXML
XML-Pull

And the new library that I'm building as I develop the pages. The new library is BigIP specific and will be available when it's completed - though it will require kSOAP, which requires the other k* libraries listed above.

It's bigger than I'd like - about 87.5K and growing - but still reasonable on the Blackberry.

The only oddity I haven't been able to resolve yet is that the kSOAP class that handles http basic authorization returns with just the auth cookie on the first call, and the library doesn't handle it correctly. Not a big deal, it just appears to fail, and you catch the error and resubmit, but it is a bit clunky.

There you have it. I've created a thread on the forums to discuss the project in case anyone is interested. Go there

Here's a picture of the System Information page from our test BigIP

Yeah, I'm having fun, isn't that what work is for?

Don.

Reading: The Blitzkrieg Myth, John Mosier
Imbibing: Water and coffee

Careful what you wish for...

Don MacVittie — Tue, 06 Mar 2007 01:15:28 GMT

Well, I'm working on a Blackberry application that uses Web Services as the backend. This should be a relatively simple thing to implement since the Blackberry supports Jax on-client, right?

It would be, but the crowd at RIM agreed with me - some solutions are not suited to the XML-everywhere craze. And cell phone networks are, in their opinion, one of those solutions.

I've worked in Cell Phones (CDMA only), and can understand where they are coming from. XML is a bandwidth hog, and cell phone data packets aren't exactly the fastest solution on the Internet.

But from the developer perspective, what a PITA. Yeah, I said it. But my issues are with implementation, not their conclusions.

You see, the world is demanding that they support web services, because everything (and I do mean everything) has moved that direction, whether that was a wise choice or not. Seems simplification is more important than performance these days. Now if you're the owner of the BlackBerry, I would think that, facing the realization that something must be done, and owning a Java-based device with an XML parser already installed, you would just support web services directly.

They didn't. Instead, the team at RIM spent a bunch of time and money putting together the MDS - a web-server generating tool that communicates with Blackberries via IP on the front end and Web Services on the backend, translating web services responses into their own proprietary data format.

Unwise, IMO. But that's the path they've chosen to take. I've played with MDS before, and pitched it because I wanted a better way. This time I need a solution that is reliable and expandable, so I'm back to MDS.

I'm not a fan of "embedded Windows" - if you've ever taken an uncritical look at how that system is put together, the phrase is akin to saying "small skyscraper", or "miniature elephant". But if RIM wanted to hand a market segment over to MS, this is a good step in that direction.

I'm considering parsing the responses myself and bypassing the issue. No, it's not easy. That's okay, I'm a glutton for punishment, and at least we won't have to throw up another server. Too bad their push methodology is tied to http, I need https.

While I'm not down to using MDS yet, I have reinstalled it and started up a project, just in case.

You never know, I might end up having to use it.

Don

Imbibing: Red Bull and Mt. Dew
Reading: Not much this week other than BlackBerry developer docs.