On Fri, Jun 3, 2011 at 4:10 PM, Leigh L. Klotz, Jr WA5ZNU <[email protected]>wrote:
> Actually, I think we should decouple the UI from the modem and services > (logging, spotting, etc) set and use a protocol between them. I've done a > couple of versions of this in the past, and believe that an HTTP based > approach is the right one now. (It's not quite what we have with XML-RPC, > but similar. I'm not going to complain about something that works and is > easy to author, and don't think we should move away from it, but it's not a > good play for the interoperable web space and across different digimode > application.) > I think you are right on and starting to think in terms of an integrated system. I am not sure that I would pick HTTP other than it certainly is ubiquitous. > Right nowI'm working with a few other people who've had this same idea. > The main reason I propose this is because it lets the modem and > software-hard developers do their thing best, and lets the UI designers do > what they do. So, instead of a "fork" of fldigi, if we had this type of > approach, it'd be a new front-end client to fldigi. > That does make a lot of sense. I am thinking in terms of how the system presents itself to the user and that is independent of the way it works under the hood but I suspect that how you think about the system is going to leak into the implementation. I think you need to go one step further. What we are really talking about is thinking of the "modems" (I prefer CODECs) as plug-ins to our communications system. We blur or completely eliminate the dividing line between the IF (the rig) and the CODEC (fldigi) until it functions as a single entity. That is the direction we are going. Right now because we have two pieces of hardware, i.e. rig and computer, we think they are really separate. They aren't. Heck, many years ago a top-notch receiver was a tunable IF at one frequency, something like 40m, and then we used receiving converters ahead of that to get the bands we wanted. I am sure that everyone was thinking back then that these were separate. Then Collins came along with the KWM1 and made it all look so simple and integrated. Sure the converters still existed in there but now you just didn't see them or have to do the frequency calculations in your head. It became one receiving system and the operator's life was easier. In fact, what I am talking about is *IDENTICAL*to that situation. We have a low tunable IF (fldigi) and a higher tunable IF (the rig). Instead of tuning them separately we have a single "knob" to tune everything at once. > I realize this isn't an overnight change, and so I'm continuing to work on > it in the background. A common control protocol would mean that front ends > could work with multiple different programs, and I think it's quite likely > that with or without us (us, me, fldigi, et al) this will come to pass > anyway. > Yes, it probably will. > > As an example of what this might enable, I believe that a PSK Reporter like > UI as for a digimode program is an enchanting idea, and might appeal to a > different set of people than the current style of digimode UI, which range > from MultiPSK's highly utilitiarian to HRD Deluxe's Mad Scientist. > Yeah, speaking of how to go completely overboard without any sort of thought about system structure ... > There's no reason someone who wants to do a different UI (map-based UI or a > cloud-text UI, or even like KI6IMM who wants an xboard front end so he can > play chess over the air) should have to deal with a complex modem system or > C++ or Pascal (MultiPSK) or anything at all remotely like that. In fact, I > think an HTML+JS based UI, or an Apple or Android toolkit UI should be > trivially possible, and each will appeal to a different set of people as > users and as developers. > You are one step further along than where I was starting with this. -- Brian Lloyd, WB6RQN/J79BPL 3191 Western Dr. Cameron Park, CA 95682 [email protected] +1.767.617.1365 (Dominica) +1.931.492.6776 (USA) (+1.931.4.WB6RQN)
_______________________________________________ fldigi-alpha mailing list [email protected] https://lists.berlios.de/mailman/listinfo/fldigi-alpha
