Hi Per, Rein, Yes an interesting concept Per. One of the difficulties is trying to find a balance between what everybody sees as useful (normally only proven and tested solutions even if not very advanced) and the latest and greatest that nobody wants because they can't see the value in it. Then there is the other dimension of "getting people interested" so that they embrace the solution to avoid the first issue above. Sometimes it is the "not so important" feature in our eyes that catches someone else interest. Another difficulty is to find models that make sense when they are applied in the field, at least that can be tested during drills and simulated exercises or in real situations. But there are a lot of technically interesting solutions, the problem being to find the right ones. An we have to accept that it is a trial and error process to some extent. The important in my view is that we keep having fun...the rest will come. In the mean time I feel we need to pay enough attention to the robustness of the new release as, in my experience, noticeable bugs really detract from the underlying value of the solution. Hence my continuous testing. Thanks guys for a great solution Best regards, John On Thu, Dec 23, 2010 at 7:34 PM, Pär Crusefalk <per@xxxxxxxxxxxx> wrote: > Hi John, > > Great that it worked for you. > I like the concept as we get a lot for free when using a complete aprs > suite like this. Just like you I also started thinking about having it > do more than just display positions on a map. At the moment the inbound > stream is just handled at the connect phase and if the external client > should try to send anything it will get a negative response. But, > handling incoming messages, positions and what not is just a matter of > extending the protocol handler. Its not a problem, just requires some > work and testing. > > "I wondered why the baseball kept getting bigger. Then it hit me." As > the interface already handles multiple clients I can imagine a scenario > where you have several aprs clients that use one common jpskmail socket > interface. For instance some kind of emergency drill with a big staff or > several stations put together with only one radio... Ah,well. Guess its > a solution in search of a problem? > > 73 de Per, sm0rwo > > >