As I'm continuing down the road of getting all of the Toolkit apps to 2.0 status, I've come to an interesting fork in the road that I'm not quite sure how to resolve at this point. The ultimate question is this:
Do I bundle all of the features to date into a single application and provide modules to users, or do I keep each application its own streamlined entity?
The case in point with revolves around RONIN. For those that are just coming over here [welcome, welcome] RONIN is a program I inherited that is used by Yu-Gi-Oh judges (and players) to get the rulings about a given card. Yu-Gi-Oh is pretty unique in that there are insane number of rulings. Originally, there was a website that was officially maintained that listed them all, but the interface wasn't the best. In addition, most of the rulings involved interaction with other specific cards, and these rulings weren't cross referenced. RONIN filled this gap by providing an online and offline mode of viewing the rulings, made them easy to find, and most importantly, genereated cross references to other cards so you could find any related rulings. There are some other features in the program which I don't think are as heavily used, such as getting a full spoiler list for a given set or printing out a "mini rulings book" based on the cards in your favorites list.
With the upcoming relinquishment of the roninpro and deckstudio domains (to fall under ccgtoolkit.com) I was alerted to the fact that the web services called by these programs were pointing to these domains and not to my "root" domain of dillieodigital.net. A quick update was in order. The Deck Studio update went quick and smooth, since I was using simple web references in Visual Studio and I let it "automagically" update things for me.
RONIN isn't as simple as a story. I've never had the chance to fully go through the code to piece together its inner workings, but it was originally written in the 1.1 Framework days. The creator of it really knew is stuff, and I wager he decided to manually create the web service libraries that would consume the services instead of letting the Visual Studio wizard do it. To his credit, I don't remember VS 2K3 being all that great with its web service interface anyway. However, when the code was migrated up to 2.0, the web service access code was not updated to take advantage of the new support.
After struggling for an hour or so to figure out exactly where I would be changing the code and still not having much luck, I decided to take a mental break and work on something I already had in mind, the new offline rulings database that would also be going into RONIN. I'm taking advantage of SQLite in this regard, and thanks to a wonderful ADO.Net adapter for it, I coded the entire library, and had the data dumped into the portable DB in no time. I wanted to test this out and a thought came into my mind to just add another tab to the main display of Deck Studio and drop it in there. I can easily tie into the event that fires when a card is selected, so I have the Id right at my fingertips in which to pull out the rulings text and bind it to a simple textbox or label for viewing. I already have a nice update structure in place, so as new rulings became available, I'd package that up into the database and the user would get the latest version with no hassles on their end.
So why don't I just merge everything together and save myself a lot of maintenance headaches? That's a little tricky. For a long time Deck Studio users have been asking for modules to be added to track their current collection against a built deck, or have their own custom "whoozit" run when they wanted, or even have rulings right there in the application. The original push back to this has been that Deck Studio was streamlined to building decks, and RONIN was streamlined for those wanting rulings. I know plenty of people in both camps that don't care about the other. There are definitely the power users that use both apps, but I don't think they have too many issues about using both apps. In addition, I know I went a little Firefox plugin crazy the first time I drifted over to the addons and it bogged it down faster than anything. I would fear the same consequences to users if I went that route. In addition, both Deck Studio and RONIN are using a common database already, so there is no duplication on that front, even if I did add a new application to the suite.
That said, there is something elegant and appealing about being able to add which items you want and not have to fire up multiple applications to get the work done. This sort of exists already with the Image library. If you don't have the library downloaded, no sweat, you just see a place holder image. If you want the library at a future date, it is a simple download through the update module. I see the same thing working here, especially with the seperation of the tag library, rulings library, and restriction lists into their own manageable parts. This also has less code for me to maintain and any fundamental changes to the Tournament Card Registry wouldn't have to be done in multiple applications (which is truly the heart of the applications themselves).
So that's the big divide. I have some inklings on which way I want to go, but no definite decisions yet. So I'd love any help from gurus out there that happened to stumble upon this blog. I'll do a followup down the road when I reach a conclusion.