Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Likes
« Reply #15, on January 20th, 2012, 08:13 PM »
Exactly, which is why I can't think it through as to what's best, and perhaps it's better to ignore preferences and just go by oldest first.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Likes
« Reply #16, on January 20th, 2012, 09:47 PM »
Okay. Can always be changed later...!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Likes
« Reply #17, on February 8th, 2012, 03:51 PM »
Hmm, still can't think of a good way to actually perform the colour substitution.

I think the obsessrewrite stuff needs changing slightly to move the colour separation into its own function so it can be called independently of the full buffer rewrite.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Likes
« Reply #18, on February 8th, 2012, 06:36 PM »
Can't this code block deal with this particular color substitution at the same time....?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Likes
« Reply #19, on February 8th, 2012, 07:15 PM »
That's the thing, the choice is either doing it manually or pushing a small one line string through the entire buffer...

Mind you, I suppose if it is a profile link it does have to do the PURLs replaces...

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Likes
« Reply #20, on February 8th, 2012, 11:18 PM »
Well it would...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Likes
« Reply #21, on February 8th, 2012, 11:23 PM »
Then it pretty much has to go through the entire output buffer replace then.

Just trying to think, would that happen before or after any wrapping in an XML container?

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Likes
« Reply #22, on February 8th, 2012, 11:30 PM »
Err... After, I suppose...? It does for JumpTo.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Likes
« Reply #23, on February 8th, 2012, 11:35 PM »
Ah yes, though jumpTo also manually sets up certain pretty filters :/

But yes, I can certainly look at that code and come up with something.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Likes
« Reply #24, on February 8th, 2012, 11:39 PM »
Yes it does.
We could turn it into an automatic filter, i.e. called by Wedge upon setting a special variable or something... If it could help.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Likes
« Reply #25, on February 8th, 2012, 11:40 PM »
Nah, I'll call it manually, seems easier and safer to do that.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Likes
« Reply #26, on February 8th, 2012, 11:43 PM »
Still, I have to admit it doesn't feel very natural having to manually add some filters and reset the output buffer function etc...

Okay, this time I'm really off!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Likes
« Reply #27, on February 8th, 2012, 11:46 PM »
Doing it in AJAX is inherently a special case and one that I'm not overly upset by, so it's all good :)
Re: Likes
« Reply #28, on March 13th, 2012, 10:31 PM »
OK, so I took a bit of time out to work on this today.

So far I have the core like behaviour set up, though there's no permission check (any non-guest can like content), and there's a bunch of housekeeping that isn't being carried out either. I have also got the AJAX callback set up as well, so it can AJAXively update and return the new 'x, y, whatever likes this' string.[1]

Anyway, still to do:
* tie up the AJAX stuff so it's called AJAXively and updates as such
* implement some kind of permission
* implement caching

Here's the thing. I did some studying of what goes on elsewhere, and I found that in reality getting the like data is actually going to be very awkward, not to mention unhelpful in other respects.

As it stands, we get the message ids, the poster ids and the post times early on, but bulking that query out to fetch a text field is going to make it expensive, especially if I subsequently throw all the extra ids into the loadMemberData queries, doubly so when you consider that in most cases the names you're loading probably won't be ones you need anything for except the name.

So my plan instead is to cache the list based on a page's worth of messages - I get all the like data I actually need for a page's worth of messages, and cache that as a single unit, so I can reload it as-is. So right now all there is, is the one extra table that stores likes, and nothing else. The overhead is not actually that significant especially since it looks like it's being indexed meaningfully.[2] The only need for caching is simply because it will be queried in its entirety and the information digested appropriately, but the whole point of caching will fix the side issues with that.
 1. Though because I'm doing it through the action=like handler rather than anything else, it got... upset... I had to expressly detect for and start the gzhandler buffer otherwise the browsers all cacked themselves at the content being incorrect.
 2. The table structure is four columns: id-content, content-type, id-member, like-time. This way, likes can be extended to media or whatever else with little real effort in the DB. The trick here is that content-type is a fixed width field, currently 6 characters, which should be enough to be at least representative of content, currently only 'post' is supported but there's the foundation for hooks to be able to extend it arbitrarily. But because it's fixed width rows, with a primary key of id-content/content-type/id-member, and queried that way, it should be pretty lean.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Likes
« Reply #29, on March 13th, 2012, 10:52 PM »
Looks complicated :P

Are you planning to implement a social stream at the same time?