Comments on: Features of a corporate feed aggregator http://blog.dominicsayers.com/2006/05/09/features-of-a-corporate-feed-aggregator/ Sat, 06 Mar 2010 19:50:06 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Uno http://blog.dominicsayers.com/2006/05/09/features-of-a-corporate-feed-aggregator/comment-page-1/#comment-94 Uno Wed, 18 Apr 2007 14:06:28 +0000 https://dominicsayers.wordpress.com/2006/05/09/features-of-a-corporate-feed-aggregator/#comment-94 This is an awesome idea that I think would work wonders in the enterprise world, especially when you need to spread knowledge and help people understand what RSS is. Shees I hope someone develops this! This is an awesome idea that I think would work wonders in the enterprise world, especially when you need to spread knowledge and help people understand what RSS is.

Shees I hope someone develops this!

]]> By: » http://blog.dominicsayers.com/2006/05/09/features-of-a-corporate-feed-aggregator/comment-page-1/#comment-93 » Wed, 06 Sep 2006 00:25:13 +0000 https://dominicsayers.wordpress.com/2006/05/09/features-of-a-corporate-feed-aggregator/#comment-93 [...] I should clarify something I said in a previous post about the ideal corporate aggregator. I said it could not be browser-based and when I said that I had in mind a very specific architecture that would not work in a corporate environment. [...] [...] I should clarify something I said in a previous post about the ideal corporate aggregator. I said it could not be browser-based and when I said that I had in mind a very specific architecture that would not work in a corporate environment. [...]

]]> By: andy http://blog.dominicsayers.com/2006/05/09/features-of-a-corporate-feed-aggregator/comment-page-1/#comment-92 andy Fri, 02 Jun 2006 11:20:09 +0000 https://dominicsayers.wordpress.com/2006/05/09/features-of-a-corporate-feed-aggregator/#comment-92 I dont know a lot about thes things but RSS Bandit is open source I believe, could we not add functionality to that, in house and avoid getting tied into another potentially expensive external vendor? I dont know a lot about thes things but RSS Bandit is open source I believe, could we not add functionality to that, in house and avoid getting tied into another potentially expensive external vendor?

]]> By: dominicsayers http://blog.dominicsayers.com/2006/05/09/features-of-a-corporate-feed-aggregator/comment-page-1/#comment-91 dominicsayers Fri, 02 Jun 2006 10:22:48 +0000 https://dominicsayers.wordpress.com/2006/05/09/features-of-a-corporate-feed-aggregator/#comment-91 In the context of the organisation that you and I work for, Andy, I quite agree. It would be better to get a sub-optimal aggregator in widespread use than wait for jam tomorrow. The only proviso would be that we should consider how we would upgrade the aggregator when a better one becomes available. In other words how do we preserve everybody's feed collection without a lot of manual effort? The context of my post arose from ongoing discussions with a particular aggregator vendor. Today we are discussing feature sets rather than deployment strategy :-) In the context of the organisation that you and I work for, Andy, I quite agree. It would be better to get a sub-optimal aggregator in widespread use than wait for jam tomorrow.

The only proviso would be that we should consider how we would upgrade the aggregator when a better one becomes available. In other words how do we preserve everybody’s feed collection without a lot of manual effort?

The context of my post arose from ongoing discussions with a particular aggregator vendor. Today we are discussing feature sets rather than deployment strategy :-)

]]> By: andy http://blog.dominicsayers.com/2006/05/09/features-of-a-corporate-feed-aggregator/comment-page-1/#comment-90 andy Fri, 02 Jun 2006 09:22:54 +0000 https://dominicsayers.wordpress.com/2006/05/09/features-of-a-corporate-feed-aggregator/#comment-90 Lets face it, we are not going to get the ideal corporate aggregator any time soon. In the mean time lets just go with the flow and support the RSS bandit as the prefered solution for now as it is being used by research. Any technical people who have other preferences can use what they like (they will anyway) but for us less techy (well less time to play and experiment anyway ;-) ) a supported aggregator that we dont need to spend 1/2 a day working out how to install and use will be most useful... Lets face it, we are not going to get the ideal corporate aggregator any time soon. In the mean time lets just go with the flow and support the RSS bandit as the prefered solution for now as it is being used by research.

Any technical people who have other preferences can use what they like (they will anyway) but for us less techy (well less time to play and experiment anyway ;-) ) a supported aggregator that we dont need to spend 1/2 a day working out how to install and use will be most useful…

]]> By: Dominic Sayers » Blog Archive » Corporate feed aggregator revisited http://blog.dominicsayers.com/2006/05/09/features-of-a-corporate-feed-aggregator/comment-page-1/#comment-89 Dominic Sayers » Blog Archive » Corporate feed aggregator revisited Fri, 02 Jun 2006 08:59:56 +0000 https://dominicsayers.wordpress.com/2006/05/09/features-of-a-corporate-feed-aggregator/#comment-89 [...] I should clarify something I said in a previous post about the ideal corporate aggregator. I said it could not be browser-based and when I said that I had in mind a very specific architecture that would not work in a corporate environment. [...] [...] I should clarify something I said in a previous post about the ideal corporate aggregator. I said it could not be browser-based and when I said that I had in mind a very specific architecture that would not work in a corporate environment. [...]

]]> By: dominicsayers http://blog.dominicsayers.com/2006/05/09/features-of-a-corporate-feed-aggregator/comment-page-1/#comment-88 dominicsayers Tue, 09 May 2006 17:08:06 +0000 https://dominicsayers.wordpress.com/2006/05/09/features-of-a-corporate-feed-aggregator/#comment-88 Hello Neil and welcome to the conversation. You are right that the server component of a browser-based corporate aggregator would be able to store the user's Read/Not Read status centrally (unless the developer went for a brain-dead cookie-based state machine). I don't believe browser-based apps have a monopoly on central storage for state, though. I'm talking about a corporate environment where a user's home drive (for instance) might be expected to be available in all contexts. I guess most aggregators store their state in a file somewhere. Just needs to be somewhere on the corporate network. Hello Neil and welcome to the conversation.

You are right that the server component of a browser-based corporate aggregator would be able to store the user’s Read/Not Read status centrally (unless the developer went for a brain-dead cookie-based state machine).

I don’t believe browser-based apps have a monopoly on central storage for state, though. I’m talking about a corporate environment where a user’s home drive (for instance) might be expected to be available in all contexts. I guess most aggregators store their state in a file somewhere. Just needs to be somewhere on the corporate network.

]]> By: Neil http://blog.dominicsayers.com/2006/05/09/features-of-a-corporate-feed-aggregator/comment-page-1/#comment-87 Neil Tue, 09 May 2006 13:30:47 +0000 https://dominicsayers.wordpress.com/2006/05/09/features-of-a-corporate-feed-aggregator/#comment-87 (1) rules out all browser-based aggregators, but (3) appears to rule out all non-browser-based aggregators. (1) rules out all browser-based aggregators, but (3) appears to rule out all non-browser-based aggregators.

]]>