I'm relatively new here, but I've been a professional programmer for FAR longer than I've been doing weather systems.
I've marveled at the way that people tightly couple their systems - VWS, for example, insists on doing the data logging and storage, and creating displays, and managing websites all at the same time. Maybe I'm just old-fashioned, but there must be a simpler way to design this stuff. The CarterLake stuff, seems to insist on
For example - a weather station front-end that generates a data stream (with or without tags, XML or not, I'm not sure what it should look like yet) and sends it out to a data sink, or better yet, a series of data sinks.
Maybe something like XMPP? Each sender would log into the XMPP server and communicate with listeners that are also logged into the service. This way, you can have the data captured on one server, stored on another, and displayed on a third.
The only reason I'm bringing it up is the problem I'm having getting to where I need to be with my system. I need to build a server that can listen to up to four different weather stations and collect data from each. The data needs to be normalized and stored in a database, and then excerpts of that data will be used to create graphics for various needs. We're also thinking "other uses" for the weather data - things that are simple enough, but because of the proprietary nature of the stations we're using, becomes unnecessarily difficult.
One example is a simple "X10" interface. Right now, the program we're developing to open and close the greenhouse windows has to interpret data from a JPG file on the webserver. If we had a "data network" interface, we could simply have the window manager listen in on the conversation and when the conditions warrant, change the settings of the windows.
By splitting the data reporting up from the data use, it simplifies a lot of what we're trying to do. I also noticed that a lot of people are using Visual Basic for their programs, which implies MS-Access as the database of choice. Anyone that's used MS-Access knows that it's a sub-optimal solution for anything more complicated than toys. My adding this data interface to the scheme, the choice of database becomes system independent. The data storage subsystem could be written to use Access, SQL Server, MySQL, or Postgresql. Since the interface front end is the same for all systems (XMPP again), the backends become independent, allowing for layers of data security.
Just thinking out loud....