Norman Walsh's personal site, besides being a good read, is also quite interesting due to it's technical underpinnings.
Treebeard - an Open Source XSLT IDE - built on a variety of another open source stuff targeted at "small businesses" and guys that just "got back from Barnes and Noble with your spankin new XSLT book" :) [via pwtm@]
Java is in need of a sort of "Grand Unified Theory" for distributed applications. EJB, Jini, [create JXTA], and JMS have more in common than just the letter J, though you wouldn't know it from reading the specs. [via pwtm@]
The MAD Plug-in for Winamp is exactly what it's name promises - it provides the superior mpeg decoding quality of MAD to winamp users. if you're kinda interested in high-quality audio or use your computer for cd archival or anything the like, go and give it a try. you'll never go back :)
The recently unveiled and unleashed Parss is interesting due to multiple reasons. architecturally, Parss consists of client/server parts whereas the server component "takes care about retrieving updated feeds and provides these as preprocessed data" to clients. another part of parss is a client for Antville, that allows "merged feeds" to be displayed within antville sites.
the former part, the server component, is quite interesting. i'd guess it is the result of considering that in order to enable custom aggregation for each user, the first idea would be to simply poll all the feeds, each user requests. this soon leads to the thought of a "master aggregator" that acts as a central mediator to the custom, per-user aggregators.
now as a result of this, parss is also a very interesting web-service on its own, not just for antville clients. i don't know for real, but i guess most weblog software allows to somehow customize which server to ping (yeah, the 'weblogs.com notification'). Parss has an XML-RPC api, which also provides a ping method similar to weblog.com's, although the semantics differ.
a hypothesis: it would be rather easy, to add a "weblogUpdates.ping" method, syntactically indentic to the one used by weblogs.com. two behaviours spring to my mind: 1) discard the weblogname parameter, but use the weblogurl to autodiscover the RSS feed and then proceed as if Parss' ping( URL ) was called. if autodiscovery fails, discard the ping. 2) same as 1, but if autodiscovery fails, record the ping. this would allow Parss to provide something (at least the data backend) similar to weblogs.com.
if the above paragraphs are unclear, do not hesitate to comment :)
now another thing that springs to mind, is controlled flooding to let the aggregators communicate. but, this is another story ... (and i really cannot imagine, that no one has thought of this before; more googling required).
finally: congrats tobi! parss looks fine :)
gpoul 7614 days ago:
I'm sorry, but I don't agree with your thoughts about Parss. Why in the world would someone think about doing a central RSS aggregation service because individual users generate too much traffic to individual weblogs' RSS files? Whoever would provide this service would need much more bandwidth? What's the incentive for him to provide this service and pay for the bandwidth?
IMHO a distributed approach is still the best one. But today's RSS is just not fit for it.
just my 0.02.
earl 7614 days ago:
okay :) some misunderstanding here. i'm definitely not for a central service with central as in "one for all and everyone."
parss is just a mediator for a local (!) group. i think the concrete antville/parss situation explains this in a quite unambigous way: a single antville installation can host a large amount of users (with individual site/webblogs). now each users gets the ability to use his site for feed aggregation. obviously, if say a hundred users subscribe to xyz.com/rss, a hundred individual polls would be necessary. in the concrete antville/parss situation, it is a no-brainer to register all feeds at a central module (parss) and then poll each feed only once and provide the results to all local subscribed users.
but even in certain other situations, such a mediator (== proxy) approach makes sense. even when HTTP proxies are used, a special RSS mediator might improve processing speeds (another motivation for parss, afaict).
gpoul 7614 days ago:
Well... I read the antville pages and didn't get it before posting my comment so I won't read it again :)
After you told me it makes more sense that it's a local aggregation, but still the traffic has to flow over the blog server for these users and they would have to poll the web service for new entries. It's getting more efficient because it hands the server a timestamp but it still has to poll the central server.
This system still makes no real sense to me because I think something like this should be deployed onto the various weblog servers themselves.
IMHO it makes absolutely no difference which central server delivers the data.
earl 7614 days ago:
parss typically runs on the same server an antville installation runs on (afaict).
Please log in (you may want to register first) to post comments!
search
3 active users
- unknown (3)
backlinks (more)
none, yet
recent stores (more)
recent comments
echo earlZstrainYat|tr ZY @.
