"New" Indicators for columns

[(Shovel)]

OK, this is being asked in a general sense, though in reality it will be implemented as a PHPNuke/PostNuke block, so if you have any experience with that, please do bear it in mind.

Using the phpNuke "journals" system (Columns/Weblogs to you and me), every user on my site gets a column if they want it.
By default, you have to click a "Columns" link to get the list of columnists, and then choose a column.

I want to code (php/mySQL) a block (left hand menu item) that will list all the columns that the user has not read yet, then when he does read it, the column disappears from the list. Therefore, I need a way to determine which he has read and which he hasn't.

Getting the date of the last entry is not problem, that'll just be a mySQL query. The problem I have is how to store the data of "what has and hasn't been read".

The number of members could end up rather large, so using a bitmask (one bit for each member and have that correspond to the member ID) would be impractical when the members numbers get above say, 64 (using 128-bit numbers doesn't strike me as effcicient?).

So, how would you recommend doing it? Don't worry about the phpNuke bit, just with regard to if you were to code this yourself for any site.

Thanks very much for your help.

 

[Krazeh]

cookies seem the simplest suggestion, instead of storing what people have viewed on the server store it as a client side cookie. Iirc that was how barrysworld used to store information about what columns you'd read.

 

[(Shovel)]

I guess the thing is, what do I store? I mean, storing an individual cookie for every column strikes me as inefficient? And with lots of columns it would be slow to send all the cookies on every page load.

I mention above the idea of using bitfields, this could then store a "read/unread" status for every member ID and attach a date to it as well. But the potential size of the integer involved would be gigantic...

 

[Jonty]

Hey Ben

I can't say I've given this much thought, but what about just storing the read/unread status as one long integer in a cookie. Say you had a list of all columnists in a MySQL table. Each columnist has an 'id' number attached. The cookie file would then contain an integer consisting of 0s and 1s (0 for unread, 1 for read). The position of the 0s and 1s would correspond to the id of the columnist.

Say you had 5 columnists, with ids 1 through to 5. The cookie number may look like '00101' which would mean columnists 1,2 and 4 have not been read, but 3 and 5 have. Presuming every 0 or 1 is one byte, the cookie would only be approaching 1kb if you had a 1000 or so columnists.

You then load the cookie via PHP, extract the number (or part of it, since I doubt you'll display every columnist on one page) and then cross reference the 0s and 1s to the columnist ids, and output accordingly.

Just a thought

 

[(Shovel)]

That's basically a better way of describing what I said above.

The problem (now going into phpNuke limitations here) is that every member has the ability to make a column (under some control...) but their member id (I think) is used to identify it - though I will check that carefully.

The problem I see is that is member #1 writes a column, fine. But if members #2 - #555 don't write columns, then #556 does, a bitfield method (which is what Jonty described) would required a lot of wasted space for it to correspond.

I'm going to have a good look at the mySQL table to confirm exactly how the columnists are indentified see if there's a way to zap them

 

[Jonty]

Good luck Ben! To be honest, I doubt there's really a way of getting around the problem, unless you group together the columnists which a user has read, compared to those they haven't read. Say we have ten columnists; 1,2,3,4 and 8 have been read, 5,6,7,9 and 10 have not. You could then have two variables in the cookie, one for read columnists and one for unread. You could then comma separate the values, hypenating consecutive groups; e.g.

read = 1-4,8
unread = 5-7,9-10

Or perhaps the only other way is to store the date the user last logged in and cross reference that with the columnists' entries. The new entries would automatically be unread. We then need only one other variable in the cookie, which would mark the posts the user has read. So effectively all entries are presumed unread unless the columnist id is found in the cookie variable.

To be honest, though, neither solution is great, especially when the members increase in number. Popularity has its downside, eh?

Kind Regards

 

[MYstIC G]

imho do it on a date visited & date on columns basis instead of a checklist of what has been read basis imho it'd be much easier

the other easy solution i would imagine is to just keep the list of read article entries based upon giving every column a unique reference (which I assume phpnuke will do anyway)

i.e. column.php?column=146 when loaded would add "146" to a columns read entry in the cookie, keeping a list of unread columns is pointless as anything that isn't maked as read can just be assumed as unread.

Option 3 is just ask trebz, as he's no doubt the one that coded the BW columns one & if not his stuff on daminis site keeps track of read/unread comments

 

[(Shovel)]

Thank you all, I'll have a looksie for Trebz like solutions.


Actually.. is the #webdev channel website still alive? I swear (in a random fit of random remembering) that they put some psedocode up for this very thing...

I just can't remember where it is/was...