i've gotten a few comments privately about some questions and thought i'd offer some opinions here.
first, regarding my flickr/tagging plugins. again, i've chosen codeplex to be my source of distribution/collaboration and i'm just waiting for project approval -- hopefully i'll get it shortly and then the plugins will be up there in no time.
now, on to the hacking :-)
i should point out that windows live writer is beta right now and they've acknowledged more work to come. still, it's an awesome tool and kudos to the team, especially joe for championing some of my feedback :-). because it is beta, things may change -- so heads up now. also, my suggestions below are "as-is" and have not been verified, tested, or any other synonym you could think of that has to do with ensuring things work. these are merely some suggestions...implementing them may cause unknown issues and you shouldn't blame the windows live writer team, only yourself for listening to me :-)
Q: "how does windows live writer detect my blog?"
A: great question. writer originated from the planet krypton...shortly after superman left and before it exploded. that brief time gave it the super-power of blog detection. but really, it's a method called 'really simple discovery' and if you dig deep enough in the WindowsLive.Writer.BlogClient assembly you'll see ..Detection.RsdServiceDetector with some interesting methods.
Q: "it didn't detect my blog type even though i use MetaWebLog API"
A: ah, mine neither...but i didn't expect it to. why? that's easy. MetaWebLog API is just that, an API...it doesn't belong to any particular blog engine or product and in fact, many implement it. but each implement in their own way/location. .Text/subtext use <blog>/services/metablogapi.aspx; typo uses <blog>/backend/xmlrpc to access it. so there isn't really a way for writer to intuitively detect api-based blogging engines. sure, they could have a config file that could likely look at some commonality of *known* engines and map to their default api locations, but that would grow, who would maintain it, etc....just not very trustworthy. UPDATE: i forgot to correct myself. you can, of course, implement the RSD link in your blog and then it should be fine...
Q: "my blog provider isn't supported, this thing sucks and i won't use it"
A: ouch, that hurts. it doesn't suck. in fact it is quite good and extensible. your blog provider doesn't work? hmm...what one are you using?! likely it implements a common api and you can find the url for it. but okay, i'll give you the benefit of the doubt...maybe you're using something crazy like loggo or something. let's take a look at how you might start implementing support. caveat: again, this is my opinion and as-is.
1) first, ensure that you've at least run writer one time. heck even create a free blog on spaces to try it out. if you don't run it once, don't bother going to step 2
2) next (did you run it first yet?) look in your user settings directory (on xp that is your 'document and settings folder'; on vista it is your 'appdata' folder) and look for the 'windows live writer' folders, namely one called 'resourcecache' -- did you find it? go to step 3.
3) dig deeper into resourcecache until you get to the windowslive\writer\blogclient\providers folder...take a look at that little gem :-)
4) add your entry to the bottom...ensuring a guid and a unique reportingKey value. NOTE: writer may implement more that overwrite this and in fact if your wanting to know where these definitions come from, you could snoop a bit further.
once you do this, you'll notice the wizard now has your blog in there. now, that's all fine and dandy but of course, that's just the ui, you'd of course have to ensure that your blog engine supports the posting apis, etc. in fact, this is only a quick hack i noticed and now that i think about it, i think you'll have to do a bit more...so take a look at BlogClient as well.
Q: how do i build a plugin?
A: first, get the SDK. then start playing around. here's the quick and dirty. a contentsource is the simplest type, you provide some mechanism to get or play around with data, user input, whatever -- then the end result is content you send back to writer...that's it. this is what i'll call a one-way implementation...if the user made an error, they'd have to delete and start over. for some situations that is fine. the other type is a smart content source. this is like the windows live local map and image implementations that are there in writer. you can play around with user input, yada yada, but when you also click back in the editable area, the side panel turns into an edit view of that content source. this is the powerful one, but takes a bit more time and forethought...
so there's some quick answers to some questions i got...