Previous Entry Share Next Entry
Hmm. What would Space-specific Comment Properties look like?
jducoeur wrote in querki_project
Mostly just food for thought, but this occurs to me as I am building the Conversations tables:

To be properly Querkish, a Querki Comment isn't simply going to have a flat ASCII payload. Instead, it will, in good Querki fashion, be a full Property bundle. At first, that's just going to contain one Property -- Content, which will be a Large Text or a Plain Text depending on how worried I am about the security implications of allowing QL in comments -- but in the long run I think we'll allow that to be extensible.

Obviously, this will eventually allow LJ-style Properties that we will standardize (Subject is an obvious one, as are Icon, Mood and Location), but it seems likely that we'll eventually allow Spaces and Apps to define Properties for their Comment threads.

That said, this is a bit of a solution in search of problems, and I haven't decided whether it is actually all that useful. I'm curious: do y'all see uses for user-defined Comment Properties that you might put in your Spaces?

  • 1
Well, there are the obvious ones like date and time, and poster id. But it might be nice to extend comments the way something like soundcloud does. Soundcloud lets you tag exactly the point in the soundtrack that your comment is related to. Youtube annotations can do this too. A sort of footnote system for media. If commentators can do this same sort of in-line commenting, you'd need to store a handful of properties around that as well.

It occurs to me that commentator controlled visibility settings might be a useful property for a comment to have. That way a commentator could direct a reply to be visible only to the item commented on.

Interesting sounding, but I'm not sure I'm getting it -- can you expand on this one a little?

Erm, I seem to have missed a word or two. I meant that last line to read 'visible only to the poster of the item commented on'. Sort of a superset of screened comments.

Ah -- yeah, that's plausible, and probably not worth a real DB column, so it might make an appropriate Property...

I don't have specific use cases for *me* yet, but these are possibilities that leap to mind.


Moderation Status.

Does it make sense to have Comments as a Property *of* Comments? It might be one way to implement threaded conversations, I suppose...

Up/Down Votes.


Plausible -- actually, might be useful enough to wind up standard.

(Although there are different kinds of Tags, which have to be handled differently for efficiency reasons: LJ-style Memories absolutely have to be a different mechanism, due to their cross-Space nature.)

Moderation Status.

*That* is probably going to be built right into the table, for efficiency reasons -- moderation is a first-class universal notion in Querki (for a lot more than just Comments), so it gets more reified support.

But it's a fair point that more-sophisticated moderation workflows might well want to be realized (and extensible) in Properties.

Does it make sense to have Comments as a Property *of* Comments? It might be one way to implement threaded conversations, I suppose...

Could be, but it opens up a host of complications, and is hard to do efficiently. In general, the threading model is going to be baked in first-class. (Although some display options might be Properties.)

Up/Down Votes.

Interesting point. Actually, that one's potentially a can of worms that I should think about: Facebook-style Likes, which record who upvoted each individual comment, aren't obviously easy to implement in the current model. I should think about that. Properties *may* be the right way to do it, but I'll have to chew on the statistics there.

(The complication is that I generally think of a Comment as near-immutable. So upvotes, which by definition are post-hoc, don't obviously fit the model. But it may be the right approach anyway.)

  • 1

Log in

No account? Create an account