Qwest

It has come time to consider a phone system. While most of the company clan uses mobile phones for personal calls, we do have sales and support that do need real phones, with voicemail, multiple simultaneous dialtones, etc. We tried the Vonage thing, but that had too many "can you hear me now?" moments for a business to suffer, so we went to the multiple Qwest lines, which required little in equipment investment but is far too costly each month -- not to mention every time we move or want to add a line.

Last week we got a pitch from Qwest reps. The part that probably does make sense is doing a T1 with dynamic bandwidth allocation and integrated access, opening up some channels and handling all the phone switching from a box. (Not sure if Qwest is best choice for that, but I'll reserve judgment for now.)

The part I'm less sure of is the Oracle Cisco box they are bundling with the service package. They are going to put some numbers together but my hunch is that it's going to be just a tad more expensive than we are wanting (or even able) to spend.

It's also a closed-source solution, which gives me pause. Any time I'm plunking down a good chunk of change, I want to know I have ownership of the future. While I don't figure on Cisco going away anytime soon, past experience has shown that a company doesn't need to go under to EOL a product line.

There is Asterisk, which is open source. It even has a Drupal module for integration with Drupal (maintained by fellow Boulderite hunmonk). I plan on giving Chad a ping to see what kind of insights he may have. And Matthew has some measure of experience with it.

But just because it's open source doesn't mean it's enterprise-ready. This phone system realm is completely alien territory for me. Any recommendations? Warnings? Happy tales with flowers and dancing cats?

I've spent my Sunday morning mostly online. It's a lovely day, sunny and cool outside, and I've been wanting to get outside and do stuff. But I wanted to catch up online with some blogging and reading and such.

Which means that I've spent a bit of time struggling with the pathetic, slow, DNS-forgetful DSL service from Qwest I have at home. Every page view was taking ages to load. (How does Qwest even stay in business? Oh yeah, I forgot.)

And what's worse, among the slowest sites to load this morning was your humble hostess' own blog. And it wasn't just Qwest making things slow to start with -- it was the widgets. The slooowwwwww widgets. I'd sit there, watching the sun rise higher and higher while I wait for "Read" and "Transferring data from" messages in my status bar cycle through all the different services trying to load their widgets.

The. Widgets. Must. Go.

Into my feed-reader steps a new post from friend and pingVision colleague Greg Knaddison on how he just killed all the widgets on his blog. And rather than just rant about the woes of having page loads slowed down by widgets having to load from different servers in the far reaches of the virtual world, Greg has some useful advice for the widget-makers out there:

As I've pointed out, the problem can't be solved by "get faster" solutions like just speeding up the internet connections of users or making the servers that run the widgets faster. That would certainly help, but the "more files" problem means you are still limited to a few widgets.

The real solution, in my opinion, lies in solutions that are integrated into my site's software. Don't give me a flickr javscript widget - give me a flickrrippr module that pulls my photos into a local cache. Don't give me a comment plugin that takes years to load - create the "intense debate" by reading my comment rss and aggregating that information with some form of universal login so that my comments can be tracked from blog to blog (if I want). Having integrated applications you can take advantage of javascript and css aggregation/compression to reduce those files from 10 to 2. That helps.

Of course the problems with my solution is that 1) it requires lots of things like microformats that are only slowly picking up 2) site users will need powerful website building software that can be more difficult to install 3) some of these widget companies have "collect lots of data and do stuff with it" as a business model and they can do more of that without you knowing about it when they do it in this format.

Greg is dead-on. Maybe we can collectively "scratch our own itch" in the open source world (and in particular, Drupal) to help bring about widget reformation.

Meanwhile I'm going to rip out the widgets and put them into an "about me" post, so they are still there but don't drag down the entire site with every page load. I'm going to do that. Soon. Right after I get out and enjoy some of this gorgeous fall day.