One thing which I've noticed as I progress through my programming career is that I tend to like the "lost puppy" causes. When something is being ignored (generally not on purpose) or has lost its champion, I like becoming the champion for that cause.
For example, when I first started with REAL Software, the networking code was fairly taboo to work on. It was very dense code, and had a tendency to be fragile. No one wanted to touch it. So I picked it up, mashed it around, and now it's a very robust piece of code. It's about quadrupled in size (and scope), has a plethora of comments, and is accessible for any of the engineers to work on.
It's a similar story with the serial code (though Joe did enjoy working on it to a certain degree). While that code isn't quite as extensive as the socket code, I really did work it over on OS X/Linux and Windows (I never even tried with Mac Classic due to the complexity of working with those APIs).
Another good example would be the Windows Functionality Suite. I felt that there were no good free projects in the community which extended the Win32 offerings like there were for the Mac, so I started that up on my own time and it's blossomed into quite the project. I was slightly surprised to see that I've topped 25,000 downloads since I started it back in May of 2004 (can you believe it's been over two years now?), and the project is still in active development.
So I've recently found myself monkeying around with plugin code to a large degree (mostly by accident). I've never really written plugins before, and for the most part, have managed to stay out of that part of the code base for a long time. Granted, I've done some plugin work (SSLSocket and GameInputManager are both internal plugins I've worked on, and I ported the SDK to VC 6 and VS 2005). But I've never been terribly comfortable working in plugin land because I wasn't fully aware of how it all worked under the hood. I hate using magical things that I don't understand because it's very easy to accidentally abuse something. Well, lately, I've decided it's time to get over my fear of plugins. Joe was the main plugin SDK guy in the company (with William and Jon as his backups), and since his departure, no one's really stepped up to take over ownership of the SDK (though we've all pitched in to do work on it -- I've seen every engineer's initials in the plugin source base since Joe left; especially William and Jon). So I've started learning more and more about how the plugin architecture works, and have been expanding the example projects for the SDK. Now that I've got a few more examples under my belt (not nearly enough to consider myself proficient, however), I've started playing around with adding functionality to the SDK as well. It's really a fascinating piece of work (especially given the fact that it has to be cross-platform and cross-version and has been around since the dawn of time) with lots of interesting ins and outs and I've really enjoyed learning more about how it all fits together to form a complete solution. I'm quite excited to learn more about it, and hopefully contribute to the project in a more meaningful way. I am a voracious acquirer of knowledge when it comes to programming, and this is one aspect of the product in which I'm starting to gain an interest. We'll see where my code spelunking expeditions take me and what comes of it. I'm not too worried that the plugin SDK will become a lost puppy in that no one wants to touch it. I know William and Jon still actively work on it. I'd just like to contribute to it more, and perhaps become a Joe-like evangelist for it. Because, I don't champion enough things as it stands. ;-)
Now if we could just come up with someway of having RB-Compiled Plugins, but then I've never understood the argument "It's in C++ for things you can't do in RB." RB was made in RB ( minus the compiler, which I'm sure could be built in RB, but I don't have the knowledge to accomplish it ). I'd love to have compiled plugins built with RB. It would simplify my life substantially, especially with GraffitiButton.
If I knew how to code in C++, to do the things that "aren't possible in RB"...then why would I use RB...just doesn't make sense to me.
Anyhow, I'd really like some worthwhile information as to why RS feels RB-Built plugins ( which are included in the compiled binaries, as the current plugins are ) are not feasible and/or not a worthwhile venture.
Of course they're worthwhile; that's a solution we've been striving towards since as long as I can remember. But there are a lot of technical steps which need to take place before it's possible. So in the interim, you've got the Plugins SDK so at least you have an option. Eventually plugins will be made in REALbasic as well, I'm sure.
I can't wait until this comes about. In the meantime, I suppose I'm stuck with using classes. :: Sigh :: Thanks for the input, though.
I'm also looking forward to RB based plugins. Coming from a VB background, the RB plugin scheme immediately reminded me of the days that custom controls (.vbx files) for VB had to be written in C++. It was quite empowering at the time when, in VB5 I believe, you could create controls and control libraries using VB itself.
Yes, VB5 saw the introduction of ActiveX controls, and also a special version of Visual Basic 5.0 which was meant solely for creating ActiveX controls( VB5CCE, Control Creation Edition ), which did not allow any sort of compiling, but was for just for showcasing the new functionality( IIRC )
Whohoo!! Wii...need a champion....my friend....
Please version control it! It's no fun digging around finding n arhivess of the version control not knowing which is which without guessing at date stamps or ...
It's also great to have a "point" person for those wonderful esoterics like "why can't my pre-emptive thread call back into RB.."