| Comments

so i consider myself a geek...let's get that out in the open (which explains the reason for the random thought that will follow).

i was reading the blog of scott watermasysk and came across this post regarding CommentRSS.  it was prompted from him reading a post about comments on blogs and how it becomes increasingly difficult to “keep up” with the conversation:

“One items (among many others) that came up is it is sometimes hard to keep up with secondary discussions (ie, comments) via blogs. Agreed. One thing .Text and a couple other blog tools now support is CommentRSS.” [scottwater.com/blog]

another interesting point that rob made:

"Personally, I think the blog phenomena is awesome. Collecting information from it is difficult though. It means you have to read everything everyday - I can tell you right now that's pretty challenging. Just trying to follow some of the recent discussions on my blog has been challenging to say the least ! For example, to follow this discussion I have to visit your blog along with any other person's blog that wants to discuss it - it's easy to miss stuff. "

after reading that, i started thinking...why “blog”?  i thought of another technology that has been around a while and already serves a similar purpose (and solves the above problem)...you might have heard of it: newsgroups (aka nntp protocol stuff).  i started thinking about outlook express and how i keep up with the international tech community and involved in microsoft newsgroups...this is what i discovered:


post via webXXno clear winner, both use http and standard web browser
post via client appXXmaybe blogs have the edge because they implement the post via http, helping those bhing firewalls, versus nntp
topic based discussionsXXno clear winner, this is the goal of each
anonymous postingXXno clear winner
secured postingXXmaybe newsgroups due to usual implementation of network credentials versus application-based security
threaded discussionsX (kinda)Xfor me, newsgroups win...that is their intention; blogs try to implement this with comments, but the end user may have to go back to the blog site to read the comment...and usually the author of the post receives the comment in email, then has to launch their blog client/web to respond back on their blog
client apps to read the informationXXblog clients are usually rss aggregators which may or may not support some features, so if you want a client that reads the post and all responses, the newsgroups win here...again, that is their goal.
leverage post informationXX (in theory)i'm referring to aggregation here...in theory an app could be written to consume newsgroup information (and has), but blogs have a winner here with rss standardization
galleries/categoriesXX (kinda)blogs clearly have the edge here, but i could argue that newsgroups have categories...you subscribe to the one you want on the news server...think of the "blog" as the news server and the categories as each newsgroup...but it is clear that newsgroups don't support galleries
searching/archivingX (in the client)Xif the aggregator client supports it, then it will; but newsgroups have this support natively...if you can point be to a weblog software (not the client, but the weblog like .text) that enables searching, then i'll shut up)

so what's my point? it's that “blogs” have been around forever...in a different format and have usually been preserved for corporate use...

“yeah, but you have to have a news server to host nntp groups”: true, but you have to have a web server to host a blog

“yeah, but a web server is easy and i can get a blog from a service that provides them”: a newsgroup server is easy as well, and maybe there's an open market out there? a newsgroup server for “weblogsnewsserver.com”? and you can signup for your own newsgroup just like you sign up now for your own blogspace.

“what about aggregation...i want to read all in one place”: i agree...outlook express and other newsreaders do this for you...maybe they could support an rss integration consumer?

“firewalls man, firewalls”: totally agree...this is the kicker...why are it admins so scared of nntp anyway? with proper management it shouldn't be an issue moreso than http...lock it down and have security policies and all is well.

anyhow, just some thoughts...the post on pascal's site made me think...is the wheel being re-invented?

| Comments

here's a doc outlining some of the new technologies in c# whidbey...

a preview of visual c# and c# whidbey (word doc)

| Comments

just released article about asp.net process identity/thread “stuff”.


| Comments

i get a few emails about some asking what other web parts i may have...here's what i'm working on:

  • “document library explorer“ aka “doclib explorer“: this is going to be a windows explorer like view for all document libraries (security integrated) within a site.  at first pass it will support wss only and not sharepoint root sites (maybe).  some functionality will include showing the pending/rejected documents for those who have permissions, as well as showing which ones are checked out
  • “pop3 explorer“: this is a simple utility tool...not meant to be a pop3 client at all.  i've been working on this one for a while to throw some ideas around and decided the best core functionality will simply display the “inbox“ headers, not message retrieval...sharepoint and webparts (imo) aren't meant for client replacements.  so at a minimum, you can drop this on your site (or mysite) and set up your profile, and have a view of your pop3 mailbox inbox.

both of these should be done by year end, with pop3 explorer coming first (almost done with that one)

any ideas on other ones (generic of course for everyone to use) are appreciated...if you have a custom need, let'$ talk ;-)

| Comments

i've been working on minor enhancements/changes to feedreader and 2.1 is tentatively scheduled to include the following:

  • pre-authenticating user request to allow user authenticated proxy servers
  • moving the proxy server and cache settings to shared web part properties only
    • this is so that each user would not be required to change (or be able to) this information for more granular control over performance
  • changing the feed url listing in the toolpart to use newlines instead of separating each url by a “;“ character (note: some url's have a semicolon as a legitimate character)
  • adding the ability for the description to only display N number of lines
  • enabline expand/collapse ability on the feed item nodes, so that if description is displayed it will display collapsed and the user can view it but not consume massive amounts of real estate

so i am looking for other suggestions (if any).

one problem i have that is not going to make the upgrade fun for anyone is whether or not i should change the versioning.  technicall i should as it is a different version...however sharepoint doesn't make it easy to upgrade web part assemblies without using assembly redirection (which would require modification to the sharepoint web.config)...any ideas on the upgrade are appreciated...the goal being minimal (preferrably none) changes other than a new deployment.