Access Flex 6000 basic info through web browser

Are resources becoming an issue? Can resource-intensive features have an on/off switch like WNB? Use it when needed?

Or crate a MIB' internal to the radio and have NGINX or other mgmt console directly connect to it. That would be loads of fun creating hundreds if not thousands of jr system administrators that would keep the employees at FRS tied in knots explaining every internal metric available and what the combinations and permutations mean.. if you think about it, SSDRfW tracks many of these metrics and DDUtils tracks the others. Maybe the MIB can wait until the 7000. Personally, I'd much prefer FRS focus on whatever features can still fit into the box and drop the other distractions.

The thing about Apache2 Eric is it just serves up static pages, which is actually good as it has been around since dirt (so to speak) and is very efficient at what it does and largely bullet proof. For dynamic content which is what people are referring to you need a different container that is designed for dynamic content. Apache2 can act as a passthrough controlling the network side of the request/response but, in a controlled setting like behind your router, something like Jetty, Tomcat, Glassfish, Geronimo, is better, Tomcat or Jetty, being the lighter weight container as it is primarily a servlet container vs an enterprise container.

Think of SSDR (the radio) as a publish subscribe model. A app, any except for an app accessing panadapters and slices, connects to a radio it sees and subscribes to certain 'topics'. Currently, only a single app can register interest in panadapters and slices. Periodically information on those topics or, in some cases, completely asynchronous, information is deliver to all 'registered' clients. The client app then simply displays the received information. This is how SSDR is, relatively speaking, light weight. Information received and parsed from the radio is stored in radio attributes. A UI field links to it's peer attribute such that when that attribute in the radio instance changes it is automatically reflected in the display widget. But, as far as a SDRCat-like applet, how is that different that what DDUtils already displays?

Not to speak for Sal but I perceive the difference in what he is asking for is a web app to deliver the data to a browser. This would require a application container such as IIS (yuck, too heavy weight), or something like Tomcat that serves dynamic content.  If it is placed in the radio, that represents a lot of real estate just to make the data available at the same ip address that ssdr connects to.

Each one of these apps, be it SSDRfW, SSDRfIOS, XPSSDR, DDUtils, FlexMeter, etc connects to the radio and provides it with a UDP endpoint for itself. Let's say they all ask for the same information, each time that information in the radio changes the radio has to send a UDP packet to each application that registered interest in it. Most, if not all, apps using flexlib ultimate tell the radio they are interested in everything as that is what the Radio object's connect() method does.

But, yeah, I kind of agree with Sal that it is an interesting thought exercise.

CGI? Wasn't that seriously before your time? Nobody does CGI anymore...maybe in highschool??? Certainly nobody professionally, it's a huge kludge.