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

[Anvilfolk]

I honestly have no clue... but I know that those things can be really finicky given the experience signing jars that some people have had in my research lab. I wonder if it's possible to have it accept unsigned jars somehow?

[Angle]

Well, alright, I solved the probelm, which was that it was looking for the jar in a lib folder that wasn't there. I solved that by having nested lib folders, which is dumb but whatever. NOW it doesn't want to work cause the mongo db library is unsigned, and firefox won't let it work when the projects are all unsigned.

[Anvilfolk]

I think there's something I don't understand. The java stuff should basically be running on its own. All it's down is it has a socket that's awaiting connections. How is javascript become aware that it's even a java program running? All that the javascript client-side application should be doing is opening a socket?

[Angle]

Well no, I'm using Java for the sockets and javascript for the display. The java needs to go and pass the information it gets from the socket to the javascript which displays it, and then passes back requests for new information.

[Anvilfolk]

Ooooh, I see. I guess this would allow you to not really have to reimplement AgoraLib in JS?

Do people actually have to run Java on their computer then?

[Angle]

Yup. On the other hand, programming the networking part of AgoraLib in JS such that i works with JAgoraServer looks like a gigantic pain, so this lets me skip that. and if at some point in the future someone programs that, it'll be easy to switch over to using it instead.

For the moment, I'm working on seeing if I can compile the BSON library myself and sign it. I found the source, and even loaded it into netbeans but it's not loaded as a java project. SO I need to figure out how that works now.

[Anvilfolk]

Yeah, I still can't figure out how JS became a thing...

[Angle]

Alright, so I have the basic interface working over the web. you can view threads, and while clumsy, it's sufficient for the moment. Now I'm thinking we should consider changing from having separate threads, to having the whole thing be one big graph, which one can pull individual arguments from one at a time. SO you view the top level, Agora, and it has replies to it for different categories, like Politics, Religion, etc, and they in turn have sub topics, and then eventually individual threads, and you follow the links all the way down in the same manner.

[Anvilfolk]

Things are already that way!

Querying for one argument at a time is incredibly inefficient, which is why right now we are querying thread by thread. But nothing is stopping an attack from connecting two arguments from different threads. The threads are simply an aid to navigating Agora like you do in a forum!

We do still need to know how to handle "merging" graphs. What's happening right now is that attacks that connect the thread you asked for to another thread will have a "bogus" argument on one end, with just its ID and threadID. Using that threadID though, you can grab the thread. We just then need to merge the old thread we asked for first with the new thread.

[Angle]

I was suggesting that we abolish the thread/graph dichotomy, and just have everything be a single huge graph, including  categories. This'd mean we'd only need one method of navigating the thing, instead of several.

The main problem there is that threads can easily become huge - well over a hundred thousand posts huge. And in this system, they'll likely get even bigger. So grabbing an entire thread at once is also rather inefficient. Perhaps if we grab a post and all the posts in response to it?
 I'll look into merging graphs. It doesn't sound too hard...

[Angle]

Welp, this is what I came up with. It seems like it might be horrifically inefficient when working with large graphs, but it should do the purposes of the client, where you shouldn't have more than a couple dozen nodes to work with, and will only be adding one at a time. I haven't tested it yet, though.

Spoiler (click to show/hide)

Code: [Select]

public void merge(JAgoraGraph graph) {
            for (JAgoraArgument arg : graph.getNodes()) {
                boolean alreadyPresent = false;
                for (JAgoraArgument localArg : getNodes()) {
                    if (arg.getID().equals(localArg.getID())) {
                        alreadyPresent = true;
                        break;
                    }
                }
            }
            for (JAgoraAttack attack : graph.edgeMap.values().toArray(new JAgoraAttack[0])) {
                if (!edgeMap.containsValue(attack)
                  && nodeMap.containsValue(attack.getOrigin())
                  && nodeMap.containsValue(attack.getTarget()))
                    edgeMap.put(attack.getID(), attack);
            }
           
        }

[Anvilfolk]

Sorry, I guess I didn't explain myself very well

Right now, we have basically a huge interconnected graph. It's just annotated with threads so that it can be navigated like a forum. I think it's a good idea for us to have more query types, but it's also important that we not go overboard with it so that we have to implement a bajillion functions in every AgoraLib implementation

[Angle]

This'd only take one extra query, getArgument(). returns a graph containing the argument and the posts immediately connected to it.

[Anvilfolk]

Usually you'd also like to get the attacks that lead away/to all of those arguments, so that you can keep asking for more stuff at the fringes!

[Angle]

Well, the idea was that the peripheral posts are the things leading away, and you're only adding one post at a time. But yeah, that sounds like a good idea.