Clan x86
Technical (Development, Security, etc.) => JavaOp Board => Topic started by: Lance on February 24, 2010, 09:25:43 pm
-
I am posting in this thread classes that I think should be moved from the core to plugins so JavaOp is more modular.
I think Battle.net should have its own plugin (named Bnet, possibly making BnetLogin and BnetEventProcess parts of the plugin) to hold the protocol-specific classes. Of course there are plugins that use these classes from the core, but there is nothing wrong with having more than one project on the build path right? :P
com.javaop.util
BnetEvent > Bnet
BnetPacket > Bnet
BnlsPacket > Bnet
Profile > Bnet
com.javaop.users
Statstring > Bnet
War3Statstring > Bnet
com.javaop.constants
PacketConstants > Bnet (This is heavily based on the Bnet protocol :P)
com.javaop.bot
PacketThread > Bnet (This class is horribly dependant on the Bnet protocol and needs to be modularized somehow)
Once those are moved, adding IRC functionality and such will be a breeze ;D
-
I am posting in this thread classes that I think should be moved from the core to plugins so JavaOp is more modular.
I think Battle.net should have its own plugin (named Bnet, possibly making BnetLogin and BnetEventProcess parts of the plugin) to hold the protocol-specific classes. Of course there are plugins that use these classes from the core, but there is nothing wrong with having more than one project on the build path right? :P
com.javaop.util
BnetEvent > Bnet
BnetPacket > Bnet
BnlsPacket > Bnet
Profile > Bnet
com.javaop.users
Statstring > Bnet
War3Statstring > Bnet
com.javaop.constants
PacketConstants > Bnet (This is heavily based on the Bnet protocol :P)
com.javaop.bot
PacketThread > Bnet (This class is horribly dependant on the Bnet protocol and needs to be modularized somehow)
Once those are moved, adding IRC functionality and such will be a breeze ;D
I agree entirely, except for PacketThread. PacketThread should be split so that the work directly with the socket remains where it is, but the raw data is sent to the other half of the class in the battle.net code. See, I'm not sure how to handle that though, since that'd require ALL plugins that use packets to have their own packet thread, but if I don't do it, we can't support anything but Battle.net.
It's a rock and a hard place issue. Hopefully I can address it after 2.1.3.
-
I am posting in this thread classes that I think should be moved from the core to plugins so JavaOp is more modular.
I think Battle.net should have its own plugin (named Bnet, possibly making BnetLogin and BnetEventProcess parts of the plugin) to hold the protocol-specific classes. Of course there are plugins that use these classes from the core, but there is nothing wrong with having more than one project on the build path right? :P
com.javaop.util
BnetEvent > Bnet
BnetPacket > Bnet
BnlsPacket > Bnet
Profile > Bnet
com.javaop.users
Statstring > Bnet
War3Statstring > Bnet
com.javaop.constants
PacketConstants > Bnet (This is heavily based on the Bnet protocol :P)
com.javaop.bot
PacketThread > Bnet (This class is horribly dependant on the Bnet protocol and needs to be modularized somehow)
Once those are moved, adding IRC functionality and such will be a breeze ;D
I agree entirely, except for PacketThread. PacketThread should be split so that the work directly with the socket remains where it is, but the raw data is sent to the other half of the class in the battle.net code. See, I'm not sure how to handle that though, since that'd require ALL plugins that use packets to have their own packet thread, but if I don't do it, we can't support anything but Battle.net.
It's a rock and a hard place issue. Hopefully I can address it after 2.1.3.
How would it require all packets to have their own packet thread?
-
Because all the packet plugins are loaded by the core, not by the Battle.net plugin, so they'd be getting the raw socket data instead of packets. The only issue with that is that Battle.net is known to send packets in pieces or several packets in one clump, so there'd have to be a non-protocol-agnostic packet thread to pick these apart for parsing, not to mention it's not a good idea to trust TCP connections to have packets split perfectly, even if it's known to in the past.
-
I tried to do this some time ago and failed horribly... It was like trying to untangle a really long cable :-\
If this much needs to be done we might as well just start over and make JavaOp 3 ;D
-
That's a great metaphor. Yeah, I can't wrap my head around how this could be fixed, really.
-
Untangling a large cord is difficult, but it makes it easier to use in the end. Simalarly, Modularization would take a lot of time, but I think in the end, it would probably be worth it. Especially for people like me who have like no experience in whats going on except for a very primitive knowledge of Java.
Maybe we could take it very slowly and extract each set of modules from the core code one by one? Slowly making the change over the releases... maybe you could dub it "JavaOP 3" when it finally makes the last part of the transition.
Meh... I don't know XD I'm in high school and only have one class worth of programming experience.
-
Untangling a large cord is difficult, but it makes it easier to use in the end. Simalarly, Modularization would take a lot of time, but I think in the end, it would probably be worth it. Especially for people like me who have like no experience in whats going on except for a very primitive knowledge of Java.
The amount of time that would need to be invested into untangling is so large that it could instead be used to make something newer and more robust; this time using a framework like OSGi (http://en.wikipedia.org/wiki/OSGi).
-
Untangling a large cord is difficult, but it makes it easier to use in the end. Simalarly, Modularization would take a lot of time, but I think in the end, it would probably be worth it. Especially for people like me who have like no experience in whats going on except for a very primitive knowledge of Java.
Maybe we could take it very slowly and extract each set of modules from the core code one by one? Slowly making the change over the releases... maybe you could dub it "JavaOP 3" when it finally makes the last part of the transition.
Meh... I don't know XD I'm in high school and only have one class worth of programming experience.
Everyone starts somewhere. :)
JavaOp is in a very maintainable state right now. The only reason to move Battle.net out of the core is to support IRC, and let's face it - it'd make a pretty shitty IRC client.