Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

It works for me.

6 (31.6%)

It does not work for me.

1 (5.3%)

I'd be willing to help test it.

6 (31.6%)

I'm not interested in testing it.

1 (5.3%)

I might be willing to help test it.

5 (26.3%)

Total Members Voted: 14

[Angle]

What functions are there for getting data out of the JAgoraLib? I only see getThreadByID, is that the only one?

Edit: Looks like it is. I've been playing with it, and it seems some of the posts on the test server are messed up, cause when I try to get threads 0 or 1 it gives me errors. 2 works fine, so far as I can tell, and anything above that does nothing, which is not surprising as there are no threads above that point.

[Anvilfolk]

Yeah, that's the only one. We really need to figure out the technical capabilities we can afford to implement since getting a graph-like structure from a relational DB can get pretty expensive.

Check the database - I am not sure there ARE threads 0 and 1. I've deleted a few of the previous threads because they were no longer in the format that we needed for the DB. But definitely use phpMyAdmin to check the DB out.

Error reporting is TERRIBLE right now. That's one of the things we need to improve, definitely.

[Angle]

I'm going to add capabilities to get the list of threads from the database. Once I'm done with that I'll commit it to a branch and you can take a look, OK?

While I'm at it, though, should I add an object to JAgoraGraph to represent a thread header? Or should I just use argument for that?

[Anvilfolk]

Excellent idea! Commit to the main branch - don't worry about it! If you just add code, you won't break anything!

I'm not sure whether to the header should be part of JAgoraGraph or some other structure. My original idea was to just have graphs, which you could potentially merge so you'd have multiple threads linked together. Perhaps JAgoraNodes can have the thread information?

[Angle]

I had originally thought to just have posts, some of which could be in reply to Main Index's in addition to other posts. That requires that each post have a subject field, like the posts here, which they don't right now, as far as I can tell.

[Anvilfolk]

Each "post" is a JAgoraNode, which have an int threadID, but I think that's about all we get so far. We definitely need to have more thread information! The current hierarchy is forum->subforum->subforum->...->subforum->thread->JAgoraNode. I believe forums can be arbitrarily stacked, but we have no way to get information about any of that stuff (forums, threads, etc).

[Angle]

Well, let's see. Posts should be able to exist in multiple threads - that should be easy enough, just make the thread id thing a list.

We also might want to consider making posts have lists of the other posts the are linked to, so that we don't have to scan the entire database whenever we need to find a posts relationships.

[Anvilfolk]

The relationships are given by the attacks (JAgoraEdge), and each post (JAgoraNode) contains a list of ingoing and outgoing edges.

Allowing posts to exist in multiple threads makes queries less efficient because that makes another table. The way I was thinking this could be at least initially implemented is that each post is originally proposed in a thread, and that's what it's associated to. But the cool thing is that the attacks/arrows/relations don't need to be between arguments in the same thread. So even though an argument belongs to a thread, it can attack or be attacked by any other argument.

The way this is used would be something like this:
- Ask for thread #1
- Get curious about a particular argument from thread #2, which attacks an argument from thread #1
- Ask for thread #2, then merge threads #1 and #2

What currently happens is that arguments from other threads do not get sent to the client (until explicitly requested with their thread ID). They are, however, represented as "placeholders", hence the current isPlaceholder() method in JAgoraNode.

[Angle]

yeah, ok, that works. Though if a post replies to two different threads, which one does it belong to? whichever was posted most recently?

[Anvilfolk]

Hmmm, good question. I guess the way this will work is that you post to a specific thread (like in regular forums, though it'll be weird if you ask for multiple threads), and then state which attacks you believe should exist for that post. Until then it's just a lonely post not really contributing to the conversation.

[Angle]

Another way we could do it is to not have posts remember what thread they're in at all. when someone requests a thread, they get the first post in it, and then they can manuever outward from there. Perhaps have a thread remember it's first post and a list of it's leaves (the posts in response to it with no replies)?

[Anvilfolk]

I thought quite a bit about it, but I'm worried about database performance.

Databases can't really handle recursive queries, which is what you'd need to do if you wanted to get all arguments somehow connected to a given argument. The advantage of each argument having (at least) one thread is that you can get all arguments from that thread at once, then grab all attacks related to those arguments. That's pretty efficient (and it's the way it's currently implemented).

If you grab the initial post, then query again for the posts at 1-step, then again for those at 2-steps, etc etc, you're making a ton more queries. Not to mention that you have to send the database all the posts that you already have, so that you can grab all the posts somehow related to THOSE. And then you get an even larger number of posts, which you have to send again, and so forth.

Similar things would happen if you had to fill in the blanks from the first post and the leaves. Also, there will be cycles, meaning there might be no leaves!

[Angle]

I was thinking that the database would save a list of all the leaves, and that it updates it whenever someone posts. So it would only have to be computed every now and again, not all the time. And shouldn't there not be cycles? Since posts can only reply to posts posted before them?

[Anvilfolk]

Well, debates are just graphs, so there isn't really any reason for there NOT to be a cycle. You add a post, and that post is initially unrelated to anything. Then you add an attack saying that your post undermines some other post, and that's how they become connected.

For example, all pro/con debates will start out with a cycle, one pro, one con, attacking each other!

[Angle]

I had figured that posts would have their relations to other posts set at the time of creation. Debates would have a topic post, and then each position would be a reply to the topic post.