incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <li...@holsman.net>
Subject Re: [PROPOSAL] Fluoride
Date Thu, 24 Aug 2006 10:58:44 GMT

On 24/08/2006, at 8:29 PM, Greg Stein wrote:

>
> The original proposal:
> bluntly: f*k the g*dm*d users list. You got zero code, so there is no
> purpose to a users list. Fork that out of the dev list if/when it is
> appropriate. I'd even suggest sending all commits to the dev list to
> start with. All initial developers should see all commits. When the
> project grows, then fine: split it. But if you have two (oh, sorry,
> one!) developers, then why two lists?

fair comment... a single list will do nicely

>
> That said, I'm not quite sure where this fits in. Is the idea to get,
> say, "all people in the (corporate) department to subscribe to their
> feeds via this software"? Or is it more "a site publishing N feeds
> should do it via this software"? I'm assuming the latter, in which
> case, I'd be a little more interested in whether this software is
> intended to be the primary feed producer (from arbitrary data
> sources), or will an alternate republishing of a site's feeds.

It's the later.
They way I was envisioning was
a publisher  would have a set of N feeds

the software would respond to a ping, and/or perform a poll on a  
regular schedule,
and would fetch source feed and store it.

this source feed would then be pre-processed by whatever is  
configured via a hook.

when a user fetches the feed, he would do it via a personalized url.  
The source feed
would then be adjusted and all external links would be personalized.  
(similar to what is currently done
with email newsletters) and and another hook would be called so the  
publisher would be able to insert
a advertisement, a web-bug or picture of a banana.

when a personalized link is clicked, a hook would be called, ( say to  
add cookies back to the request if they aren't there) and then be  
redirected to the source URL.

that's how I envisioned it working. It would also need a library php/ 
java/ruby... to generate the customized feed URLs to be displayed on  
the source pages.
(something like /aggy/feed/atom/55a53ab418c5a6ae986fdb2dc2373d8d/   
for example )

It could also be used as a RSS cache without any of the post-processing.
for example, when your software has to do 100+ queries to generate  
your RSS feed for every request.


>
> Cheers,
> -g

--Ian

--
Ian Holsman
Ian@Holsman.net


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message