Some time ago I was talking about implementing an object to communicate with bittorrent trackers (the server or servers which provide an initial list of peers).
This week I've been revisiting that code, finishing it yesterday. Aaaand today I'll scrap the code.
I had gotten a platform independent Firefox bittorrent extension working long ago, with a major memory leak which led to wasted time and disinterest. I started breaking the extension into individual components that could be re-used and tested independently, the first release being the encoding/decoding component (with XPIDL and all that). I liked that release, the code is really a translation to JavaScript of the 'official' bittorrent clients bencoding, attributed to Petru Paler and remaining licensed with the Bittorrent Open Source License.
Finishing the tracker code, I looked back and saw I had been attempting to create classes that could be extended, and in turn objects that held state. The idea being that this could be a base tracker class, extended to provide additional abilities. I've looked back at the code with some disgust. I really don't think I should've approached the design that way. Sure, part of the reason for the approach was to make it easier for someone to extend the code, but predicting where/how it needs to be flexible was a waste (in this case).
I'm rewriting the code to be like the bencoding component. The object will hold no state, everything relevant is passed as part of method calls. In this case, there's a networking issue that requires asynchronous activity so I'll provide a callback parameter. If the code is useful for someone in the future, great, take the code and someone else can design for flexibility, I'll just try to focus on cohesion.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment