October 2004 Entries
Recently, Microsoft decided to retire Webservice.htc
This was a bit devastating for a couple of my intranet applications which are dependent on the technology.
Not to worry, The successor to this is WSE2 which is a much more secure and capable solution. It is also a fully supported product that does not expire until 9/30/2008. This makes it a viable solution for long term design and I am sure it will be superseded by WSE3 in time, so buying into this tech is not as big a risk as webservice.htc was.
Christian Weyer has a few articles about how what's in the SDK and how the programming model is going to change in the near future. If you haven't started transitioning over to WSE2 yet, now is the time. It's time because the last windows security update rendered certain parts of Webservice.htc useless. I used to tie multiple behaviors to the <body> tag in javascript and that is now not allowed, you will get “object is null” errors if you use this technique now.
I am in the midst of converting all my Client Calling methods over to WSE2 (which, by the way, has been put off long enough). I had always intended to do it, but was following the “If it ain't broke, don't fix it“ adage, now it's broken and I must. A warning from Microsoft would have been nice... Perhaps its time to start reading the fine print of those security updates.
As things progress, I will be posting articles about how I am using them. There is a pretty significant lack of HOWTO articles on accessing WSE2 from javascript for client offloading. This is something I am debating whether or not is still useful because the way I use the browser as a client would need a complete rewrite of some applications to change the architecture.
Not wanting to really do this, I would prefer to just create some javascript code that will replace the way I used Webservice.htc for loading XML tables into a <DIV>. When I get this first step accomplished I will surely post it here.
I started doing this a couple years ago, I don't recall who suggested it to me first.
Most people are still using silly, short, non-complex passwords because they are easy to type fast.
Before you pick a phrase, I recommend typing it a few dozen times to get the feel of it and to see that it's not to difficult to type for you. Anything with mixed case and punctuation is going to take longer to type than an 8 character word, but I even find it difficult to remember passwords like: {l3tM31n]
One of the most blatant problems I have found is that there are no regulations in the company/organization to change passwords/phrases with any regularity, I found some people have been using the same password for years, yes Years, or better yet, written on a sticky note attached to their monitor :-)
What I would really like to see is a move to hardware based keys that everything can interface with, there should be a way for us to use a standard USB thumbdrive to hold all our encrypted passphrases in a single location and interact with websites, and network logins automatically when it's inserted and removed. These things are tiny and keyfobable. Loosing the thing is probably alot safer than loosing your house key and it would be a breeze to do something like a standard lookup based on hardware.
Programs like this: http://keepass.sourceforge.net/ are great, but what I would love to see is a move towards a webservice that just automates it and will lookup your password from hardware, enter some sufficiently long (256 bit) key that must reside on the hardware, then do a lookup for a site/password combination, you still need both for the ability to change/lose your hardware, but it is surely easier than remembering hundreds of passphrases and changing them all individually on all the sites you pop in and out of.
I'm sure this will be another way for conspiracy theorists to complain about the ability to track a person.
Thanks Mike for the article and Richard for pointing me to it.
I have been doing some hefty reconditioning of one of my main apps to tighten up some queries and optimize things that are starting to burden my servers.
There were at least 3 things I didn't even think of using QA to process for me, alter procs, templates and debugging (I was only stepping through with Visual Studio, this is way faster)
QA seems to always be open when I am working on my db anyway so I can do things alot more efficiently when I am just tweaking my backend.
RE: Query Analyzer Tips and Tricks
Here. Very good read. I
have QA open most of the time and still learned a few things.
[Via Randomize]
I have been having trouble find time to work on this blog. I will have some new code to post fairly soon as I have developed a new technique for building Hierarchical XML Reports with Active Reports.
For one thing my schedule has been nothing short of complete insanity for the last month (I guess I can sleep when I die).
I have spent every moment of my free time working on XTCP to turn it into something truly useful for the Digital Media Community. One thing of note, I really, really like drupal, too bad its written in PHP or I'd use it for this blog too. Since this is a DotNet Blog, I feel obligated to use something written in DotNet, I just wish Scott would hurry up and release a new version, this one is lacking in many areas, but my expectations are high for his new telligentsystems venture. Is it just me or does anyone else find it really wierd that both the main DotNet blogging engines have far too similar company names now, newtelligence/telligentsystems.
What I maintain there is my set of (mostly) Open Source Code for the various tools I use to work with digital media. This site has a bunch of tips and techniques for working with your HTPC, this includes open discussion for anyone to help contribute their info on Meedio, MyTheatre, working with MP3s, XviD, Divx, etc.
I recently rebuilt my HTPC and you can read about it over there.
Blogroll Me!
Blog Search Engine
Copyright © 2003-2004 H. Steele Price, IV -
All opinions are my own, not necessarily those of my employer, your mother, or any government agency.