G33X Nexus Entertainment

G33X Nexus Entertainment => Current Projects => RaptorNL => Topic started by: whitelynx on October 21, 2006, 12:26:55 pm

Title: Developers' Journal
Post by: whitelynx on October 21, 2006, 12:26:55 pm
I'm starting this thread as a collection of random thoughts and questions I come up with as I go through the process of converting the old HawkNL code into RaptorNL's new structure. Anyone should feel free to reply if they have any thoughts on what I say here. (also, contingencplan, feel free to post your own thoughts and questions here as well) I'd like to turn this into a running discussion of the structure of RaptorNL. If any one question in this thread grows beyond a couple of posts, it will get moved to its own thread.
Title: Re: Developers' Journal
Post by: whitelynx on October 21, 2006, 12:41:26 pm
First, some questions I've already posed to contingencyplan and others in the Precursors IRC channel, just in case any forumites have thoughts on them:

Title: Re: Developers' Journal
Post by: whitelynx on October 21, 2006, 03:20:34 pm
I've been looking at the different address families available in HawkNL, and it got me thinking that it might be useful to have two things: subclasses of Address for each address family, and a convenience function to create an instance of the correct Address subclass, given a valid address in string form. Basically it'd parse the address to determine what address family it is using, and create the appropriate Address object.

Also, if we combine the address family into the Address class and subclasses, then we may not need to manually specify the address family when creating a ConnectSocket from and Address. We'd still have to specify it for ListenSocket, but that's fine.
Title: Re: Developers' Journal
Post by: whitelynx on October 22, 2006, 03:00:22 am
In HawkNL, (as far as I can tell) groups (http://www.hawksoft.com/hawknl/docs/nlGroupCreate.html) are basically ersatz sockets that can be written to and read from just like any standard socket that allow you to effectively do software multicasting. They're an interesting concept, and something definitely worth retaining for RaptorNL. The question is, however, how should we go about doing this? I'm not entirely sure how HawkNL went about implementing them, but they used file descriptors to represent groups, same as for sockets. Personally I think this could be done as a class instead, one which inherits from Socket. I'll have to take a closer look at HawkNL's implementation to be sure, but I think that'd be the way to go for this.
Title: Re: Developers' Journal
Post by: whitelynx on October 27, 2006, 04:32:51 am
Ok, we've been doing some massive work (https://kashmir.g33xnexus.com/projects/raptornl/timeline) on RaptorNL as of late. The next really big thing we'll be needing to do as far as design is concerned deals with how to handle what used to be HawkNL's 'driver' struct. Please take a look at https://kashmir.g33xnexus.com/projects/raptornl/wiki/Design/Refactoring (https://kashmir.g33xnexus.com/projects/raptornl/wiki/Design/Refactoring) and let us know if you have any thoughts.