|
DMI News |
Previous Entry.. Next Entry.. Get ready
August 23, 2009 03:32 Camserver is ready to go.... almost. It's about as ready as I can get it without just unleashing it upon the world. The results, initially, will be somewhat catastrophic. I am absolutely certain, for a short period of time, that the site will break in utterly depressing but amazing ways. Although I'm sure to have the main page functional in a matter of minutes, getting everything working properly will probably take a week or longer. Remember, EVERYTHING that touches the cam or visitor database will be affected by this transition, and it won't be affected well. I'm likely going to be doing some massive replacement of code in almost every program. I've tried over the last few years to make this inevitable transition easier by encapsulating all of the file activity into convienent function calls which could simply be replaced once at the time I switch over. However, many of the programs I have yet to do this with. And I can't really make any more changes to anything else right now because I've already converted many of the function calls over to the new format. I'm going forward with this whether I'm ready or not. Oh, and just to make it more fun, not only am I going to change how the data is getting retrieved, I'm also adding more fields to the databases themselves. In fact, I'm also eliminating fields from some of them. And I'm adding new databases that point back to the main databases as objects to replace previous functionality that was built in. And no, not all of this code is ready, so some features will actually disappear as soon as the changover takes place. It will be a shortlived inconvienence, but a nasty one none the less. Isn't this exciting! So here's the process, in a nutshell: I know most of you don't really care, but I'm doing this as much for my own planning as anything, so I'm going to tell you anyway. DEAL WITH IT! Here we go. Before I actually do the changeover, I'm going to make the database conversion, change the init functions to properly zero out the new fields in new records, and recompile all of the programs. I'm past the point of no return at this point, but I haven't yet broken the site. I just can't make any changes anymore without completing the job. It's possible I've already crossed that point, but at least right now I could back out easily if I had to. Nevermind. At this time, I will also do my best to recode everything that needs recoding to work with the new system. I can make sure everything compiles, but I can't really test the programs themselves until I proceed to the next step. So, secondly, all hell breaks loose. I shut down the server, do one last recompile, one more database conversion, and copy over all of the programs to the production directory, restart the webserver and let it rip. Third, I'll fix all the problems that crop up. I'll just need to be sure I've got enough time to do the second and third steps all in one sitting. That might take hours, so wish me luck with that. Once I'm sure I got all the glitches, I'll start adding in support for the audio and desktops, and music control, and other fun stuff. After all of that is done I'll move onto the next server. Most likely that will be the live update database. That's currently integrated into lampmaster, but I want to pull that out and put it into some other application. I don't see much point in having it standalone, but I'm not really sure which application to integrate it into. It gets hit often, about once every 10 seconds per user that's on the site at the moment, and is also queried for the admin page and also features like the popup that shows the list of people viewing each cam. I may incorprate this into the cookieserver or possibly the messageserver. Of course, the big fish is lampmaster itself. Part of this whole conversion process is to pull as much functionality out of lampmaster as possible so when I get to it, it will only handle the devices themselves, and not a slew of other site functions like it currently does. I've already pulled messages out of it, but it still handles the user updates, dynamic functions, and a few other minor things. I'll probably keep waitqueues in there since they relate closely to the device they're associated with. Lampmaster also requires an additional framework feature for slaving. Right now a client can have a persisitant connection to a server and poll the server for updates, however, the server won't automatically send unsolicited messages back to the clients. The other option that currently works are the sync connections. Those connections get sent ALL changes to the databases, as they're intended to keep servers on different machines in sync with each other. However, a third option needs to be added to allow for sending only selected updates or messages to a connected client, but not EVERYTHING. This will be connected as a syncmode just like the sync threads are, but there will be some selective breeding on how messages are sent out. I will likely use the messageserver as a testbed for this, since my synthclient that reads the messages out for me is a good example. While I could just poll the server for updated messages once per second, sending back messages when they appear over a persisitant connection would be cleaner, and a good test for the code. Also remaining is commentserver. A bunch of new challenges await for that, since I will be applying a lot of new features to comments, including objectifying them to assign them to other objects on the system. After that will be newsserver, imageserver, and probably something that incorporates several of these for use in the DMI documentation project. Then to top it all off, DMICMS itself, and several weeks of testing to get load balancing working perfectly. Ideally I want this all done before October 1. I'm not counting on it though. It'd be nice if I can at least have the core servers finished by then. That will give me enough time to focus on the xmas lighting project. Lots of stuff to do!
|