Office has a system by which it allows users of Outlook to share free/busy information by publishing it to some service. Since that system is Outlook/Microsoft specific, woudn’t it be nice if there was an internet standard for this sort of thing? Since Calendars these days are strongly associated with email addresses (e.g. my @hotmail.com MSN Calendar or my @microsoft.com Calendar), it would make sense to publish Free/Busy server information in the public DNS. Much like MX records in DNS tell where to send mail for a domain, I propose that “FB” records tell where to retrieve free/busy information for a domain. It could be implemented as a web service of sorts and a client can query DNS for the FB records for a domain, then contact the FB machines with the email address to find that users free/busy data. Wouldn’t that be awesome?
March 2004
Interesting New Sites
Last Time in Laguna Hills
I’m down in Laguna Hills (Orange County) this weekend in what will most likely be the last time I’m here in this house. My dad started working for Avaya as their controller in New Jersey and they’ve found a renter for the house in California. They’ve also gone ahead and bought another home on New Jersey, where they’ll be living. It’s a bit sad, since this is the first time my family will have moved in 10 years, making it the longest time we’ve stayed in once location. I went to junior high and high school here, so it’s really what I consider my home and where I grew up. Times a changin’.
Multi User DasBlog Prototype
I’ve put together a prototype of a multi user version of DasBlog. You can see two “users” at http://www-dev.redyawning.com/hyperionab/ and http://www-dev.redyawning.com/foobar/. Both of those two users hit a different set of content files as well as a different set of SiteConfigs and logs but run in the same application space. The basic way I have it working is:
- HttpHandler called MultiUserHandler intercepts each HTTP request and puts two items in the HttpContext.Current.Cache: MultiUserOriginalUrl and MultiUserCacheMap. The first one is the URL that is seen by the handler and the second one is the username deconstructed off of the query string (e.g. “hyperionab”).
- MultiUserHandler then does a HttpContext.RewriteUrl (I can’t remember exactly the namespaces since it was pretty late last night that I was doing all this) by rewriting the URL to take off the username.
- SiteConfig.GetSiteConfig prepends MultiUserCacheMap to all the times a config/content/log file is read up from the file system
- MultiUserOriginalUrl is used whenever DasBlog is constructing a URL instead of the Page.Url variable (since it’s been masked a long time ago in the page execution by the RewriteUrl call)
My current directory structure at the root is:
- /content
- /logs
- /SiteConfig
- /hyperionab/
- content
- logs
- SiteConfig
- /foobar/
- content
- logs
- SiteConfig
- *.aspx
- *.aspx.cs
- etc
The top level content/logs/config directories store the root level blog data and each of the “user”name’ed directories store the set for each of them. I’m not quite sure that’s exactly how I want to do it acutally. It might make more sense to have each user directory within the master content directory:
- /content/
- hyperionab
- foobar
- /logs/
- hyperionab
- foobar
- /siteconfig
- hyperionab
- foobar
I guess at that point, it’s just a matter of style. I also don’t have security working yet, so you can’t log in to each of the blogs. My feeling on site security and the usernames is that the siteSecurity.config file should be merged/unified for all sub-blogs and the users in the config file would have a mapping to which blog they can edit. The siteSecurity.config file would serve as the master list of the users. That would make it useful for people who want to maintain multiple blogs per blog hosting site but keep the same username.