Thinking about SPSynd

I’m kicking around SharePoint Syndication again. There are a variety of reasons. I got email from someone @ the SP Web Component Directory about it. According to Scoble, the Front Page team is interested in RSS. And the primary kicker, there’s a project going on in my group internally that is using WSS and wants to expose RSS feeds.

Glad to know it’s popular. Too bad it’s not done and I’m not sure how to finish it.

Generic feed generation works just fine. The problem is customization. I need a user-friendly way (i.e. not hacking XML in the config file) to configure the feeds. Currently, the config file specifies which lists and webs expose feeds as well as the format of the feed for different list templates. I want to move that config so that it can be managed by the administrator using a simple UI, not the XML file. But that leads to questions: Do I try and stash my config data into the existing web and list configuration via the standard object model or do I bite the bullet and store it somewhere else (i.e. another DB)? What’s the best way to add admin of the feed to the existing admin pages? Frankly, I don’t know the answer to these questions.

One way to solve this problem would be to completely refactor the solution. Instead of relying on the WSS object model, I would leverage the WSS web services. This would let me run the feed generator outside of the confines of WSS. Basically, I’d just be translating formats – the output of the web services into RSS and OPML. This would be really great for hosted WSS since it wouldn’t require any change to the WSS site itself. However, doing the security right for this scenario would be a pain in the ass. WSS web services use transport level authentication which means it’s difficult to “hop” credentials across servers.

I don’t know if the answers to these dilemmas are out there in the blogosphere, but I figured I might as well put the questions out there.

This entry was posted by DevHawk on January 15, 2004. It was posted in Development. It was tagged SharePoint.

Comments:

>there's a project going on in my >group internally that is using WSS >and wants to expose RSS feeds. I presume they know that there is already a free web part available for RSS feeds that works fine in WSS. http://www.timheuer.com/stuff.htm (I am not Tim Heuer just a user)
This comment was posted by Mike Walsh on January 16, 2004 at 1:34 AM.
I've seen that component in the SP Web Component Directory. However, that web part is for reading RSS feeds while my SPSynd project is for creating RSS feeds from WSS lists.
This comment was posted by Harry on January 16, 2004 at 7:23 AM.
We're actually going to be configuring and using SPSynd internally, in conjunction with a custom RSS reader part I wrote (which does audience targeting of feeds, individual feed caching, and has configurable options for display format), and I've been thinking about the same thing - an easier way to configure SPSynd. I've toyed with the idea of getting the schema for the configuration file, making a typed Dataset out of it, and doing up some sort of MMC-style admin console (which is part of the reason I joined the GotDotNet workspace for the project), but got sidetracked on other projects. The use of the web services might be an interesting idea - if you could set up a domain service account, then grant access to the appropriate lists to that user within WSS, you wouldn't even really need to say "this list is OK to see, this one isn't"; you just authenticate as your service account (which is easy enough - rather than using pass-through authentication, you specifically create a crendential set with the service account info) and if that user has permissions to the list, it displays. If not, no display. Done. That would alleviate the need for the "sites" element in the spsynd.config file. That said, you're still going to have the rest of the config file to deal with, so it doesn't get you out of making a nicer admin interface. :(
This comment was posted by Travis Illig on January 21, 2004 at 7:47 AM.

Categories

Tags

Series

Disclaimer

The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.