|
In considerion of hotlists and viewed_stories
|
|
By hillct , Section Dev Notes []
Posted on Sat Jun 29, 2002 at 11:19:15 AM PST
|
 |
|
At long last, I reveal my secret agenda. I have been tacking minor fixes and altarations onto my submitted patches for a year or so now, in preperation for elininating the last few special-case OPs out there, like the 'hotlist' OP. Finally all the minor pieces are now in place and the hotlist mecanism is calling out to be rewritten, atandardized and improvd. I've written about this in the past in various comments in reply to specific feature requests both here and on K5 proper, but due to the deficiencies of the hotlist mechanism I can't hotist the items and am educed to searching through all my comments and those of others to piece together the requirements around which the new hotlist system should be built. So, herein I record my master plan [insert maniabal evil laugh here] for the hot;ist system
|
First, the functionality requested over the past year or so, by various people: Hotlisting of comment threads, optional sharing of hotlists sharing of diaries and allowing users to view a list of those who are watching his/her diary.
Currently, the data indicating what is hotlisted is sored in the viewed_stories table. As such, only stories can be hotlisted. In order to be able to hotlist other items such as comment threads or even arbitrary URLs, a seperate table would be required, containing the fields: hid, uid, sid, cid, url. The URL field would only contain a value if the user entered a specific URL into a (currently nonexistant) hotlist builder that would be part of the user pref page. Other fields should be obvious, with the exception of hid which would be a hotlist ID. This field actually may not be needed, as the remaining fields strung together as a multipart key would be unique in and of themselves.
As for the OP standardization, the 'hotlist' OP is currently a special case. This was done bacause it has the bad characterisic of changing OPs in mid-proces. What should really happen is, after an item is hotlisted or de-hotlisted, an HTTP Redirect should be issued, causing a new client request to be generated rather than shifting OPs in mid-stream. Care must be taken to disable HTTP keep-alives for this redirect, lest the redirect take an inordinate ammount of time. There was a bug reported in certain versions of the perl Apache::Requet/Response package which prevent proper handling of the Connectin: header (more about this after I do a bit more research). Regardless, this is the correct mechanism and will maintain the integrity and consistancy of the scoop request handling process.
Well, the sun is out and it's time once again to hit the beach. BTW: WebTV really sucks! |
|
|
Story Views
|
|
15 Scoop users have viewed this story.
|
|
