Small chapters for faster reading

Frederick Giasson

I these days, people have less time to read. Most of us can’t sit down, 4 hours in a row, to read. Our reading will be sparse. We like to read, but we’ll read 4 or 5 pages here, another 3 or 4 pages there, etc.

Many people will read before sleeping. They will read 10, 15 or 20 pages. Reading needs to be planned like any other tasks we have to do daily.

Personally I like books with small chapters or books with pauses in chapters. I need it because I hate to lose track of my readings. If a book is wrote with small chapters, between 5 and 10 pages, or have pauses (2 carriage returns), I’ll be able to read them in minutes. Then, I’ll be able to read these short chapters between other daily tasks.

If I check the chapter I’m starting to read and see that he have 75 pages, I’ll certainly not start it for a 15 of 20 minutes of reading. Then I’ll wait until I’ll have the time to read it. It’s rare that I’ll have the time to read 75 pages in a row during a normal week of work. Then, the result will be that I’ll read less during this week.

Otherwise, if I’m starting to read and see that the chapter have 10 pages, I’ll be able to read it somewhere between two daily tasks. The result will be a greater reading time because I’ll be able to more effectively plan the reading of these small chapters with my other daily task.

I don’t think that I’m alone in this situation. Our world is changing and I think that authors will need to take this new fact in count when they will write their books. They will need to write smaller chapters to give their readers more flexibility to read their books. I think that authors like John Grisham understand this new need.

Technoratie: [] [] [] [] []

Why using SWFP rather than HTTP over SSL?

Frederick Giasson

This legitimate question has been asked by Daniel Lemire after his reading of the SWF protocol. There is my answer to his question. I added it as the section 7 of my SWFP paper.

The question is hard to answer because it depends on many factors. I’ll compare the two methods together and try to show you the differences between the two protocols.

Usually SSL is used to authenticate the server to the client and, optionally, the client to the server. With the cost of authentication certificates (about 100£ each), the normal clients can’t afford these authentication certificates. It’s why SSL is mainly used to authenticate servers.

Our goal is especially to authenticate the readers to the server. It’s a reason why using SSL as a secure channel and an authentication protocol is not so useful: because the implementation cost is too high; like the revised version of SWFP at section 5.

This is the big difference between SWFP and SSL: their goals.

A solution could be to use HTTP over SSL (HTTPS) with HTTP Authentication. HTTPS would provide the secure channel and HTTP Authentication would provide the authentication mechanism. The problem with this solution is that some feed readers only implement HTTPS, others HTTP Authentication and few implement both. Another problem with this solution is that who says HTTP Authentication also says login and password. In SWFP the authentication is inherent to the system. It’s made with the public key of the legitimate reader present in the secure database of the server. The authentication steps of the reader to the server are transparent to him. I think that this transparency feature is an important one because it simplify the process and brings non-expert users to use it. Only the simpler things, in appearance of, are widely used.

Two types of feed readers are available: the web applications like Bloglines or the standalone software like Omea Reader. Both principles, HTTPS with HTTP Authentication and SWFP, could be implemented in standalone software and the implementation time, cost and difficulty are probably comparables. However, I think that SWFP would be much more easer to implement in web applications. Why? To use HTTPS with HTTP, the web applications would need to create the secure channel themselves with the feed’s server. By example, Bloglines itself would need to create the secure channel with each private feed server. I don’t think that it’s imaginable. However, with SWFP nothing like that would be necessary because the encrypted feed is viewable by anyone who needs it, even web applications. If I check the FeedBurner stats of my blog: 30% of my readers use Bloglines. I think that it’s considerable and that we need to take this fact in count.

Another problem with the HTTP Authentication solution is that it’s not an optimal solution to our problem. If a user is subscribed to many private feeds then he’ll need to enter, each time, a login and password to check the feeds. Personally I don’t think that this is viable. Think about the pain such a situation would engender… nobody would subscribe to such feeds.

Finally one of the beauties of web feeds is that you can archive them for future readings. The problem with the HTTPS solution is that you didn’t really have the choice to archive the encrypted or the unencrypted content. But such a choice is possible with SWFP.

Technoratie: [] [] [] [] []