Suggestions for MyBlogroll
Julien Cheyssial wants to know our opinions and suggestions for MyBlogroll.
When I first thought about a server aggregator, my idea was having a web service on one side, and a smart client on the other side. I’ll try to reply to Julien’s questions from that perspective and thinking as if developing MyBlogroll myself...
1. XML/XSLT
XML and XSLT have several advantages for this kind of application. I used these technologies extensively over the past. Now that I write .NET applications, I tend to stick to the .NET framework. I used XSLT back when creating the SharpToolbox web site, where the data resides in an XML dataset, and the pages are rendered using XSLT.
ASP.NET and XSLT have their own advantages; the problem is that they don’t really mix together. I still have to find a way to better benefit from both of them at the same time.
Your first question is: “Should I go on with XSLT to render the pages?”
ASP.NET and XSLT are so different that choosing between them is decisive. Nevertheless, what I would do is still trying to find my way in-between.
I would do it in two steps.
-
I would build MyBlogroll V1 with the current technology.
-
For V2, I’d say go for ASP.NET wherever possible, and for XSLT where its advantages are obvious. I’d put the pages’ layout in ASPX files, and use ASP.NET WebControls for the components such as the toolbar, the feed item list… This would require creating some WebControls, that’s why it may be difficult to do it for the V1. I have ideas on how the WebControls could work. A WebControl is a control that renders as HTML, depending on the value of its properties. The HTML could be generated using XSLT. The XSLT would be parameterized by properties defining rendering parameters and the datasource to use. Let me know if you need help to create such controls.
The second question is: “Do I need to use objects?”
Thinking using objects lead to better design and reusability. Don’t Feed.Refresh() and FeedItem.BeenRead = true appeal to you? Using objects doesn’t remove the possibility to use XSLT: you can use XPathNavigators over object graphs to achieve XSL transformations!
But that’s not all. You should design the application as layers and services. One layer to handle storage, one layer to handle feeds retrieval and publishing, and one layer for the presentation. This layered design makes it easier to build another presentation layer (maybe you’ll create a smart client one day using winforms…).
Your next questions show that you already started to think about MyBlogroll as a service.
2. Aggregation Service
The core of MyBloroll should definitely be a service. I would say: go for a Web Service!
A client application should be able to invoke the service remotely. Today, the client application is a web application, tomorrow who knows…
3. ASP Mode
This is what I had in mind, a server collecting feeds continuously, allowing users to retrieve the content on a per feed basis. The server retrieves the content of each feed once, and serves it multiple times to users.
As you said, such an application would be highly bandwidth consuming, but this seems to be doable as Technorati, Feedster and others show.
Not everybody will be able to host its own instance of MyBlogroll. For this reason, the ASP mode is required for a full success of MyBlogroll. I’d say do it for V1.5.
4. What do you expect from a web aggregator?
I have no doubt that you are able to create a rich web application, and there is a need for this since we are not always able to install a rich client.
But my ultimate client aggregator would be a desktop aggregator. I want to work with feeds and items the same way I work with e-mails: drag&drop, move to folder, classify, search, forward…
I don’t know what THE client will be tomorrow, but I know that MyBlogroll’s value is on the server side. I think in terms of plug-ins:
- a client application handles the display and interaction with feeds and feed items.
- a client application retrieves its data using plug-ins communicating with server applications.
- a server application implements the API the plug-in expects.
I would try to partner with SharpReader, NewsGator, whatever…, asking them to support the MyBlogroll service as a source for their content.
5. Database or XML files?
XML is definitely better if you want users to install MyBlogroll on their own computer or server. If you support the ASP mode, you’d better start thinking about the volume. Anyway, one thing is for sure: you need an abstract data access layer.
I'll take this opportunity to give you some of my wishes:
- Notification icon in the tray bar to let us know when new items are available. The MyBlogroll backend needs to provide a web service with a function returning the number of new items.
- Support Mozilla. MyBlogroll doesn’t work well with Mozilla right now. (You should use the title attribute instead of alt for tooltips; clicking on feed items does not display them…
Links: