O to chodzi, kluczowe fragmenty:
1. Dokument ma tytuł “APRS SSID Recommendations”, a Bob dopisał, że zmieniono tytuł, aby nie sugerować żadnego standardu dekodowania.
2. Pisze wprost, że SSID są obecnie używane jako informal way, czyli nieformalny sposób wskazywania typowych zastosowań APRS.
3. Faktycznie jest tam -9 Primary Mobile (usually message capable) oraz przypis, że -9 zwykle oznacza krótkofalowca w pełnej komunikacji APRS, message plus voice.
4. Ale dalej Bob pisze, że pierwotne skojarzenia SSID nie są już wymaganą częścią specyfikacji, a konwencje są tylko zachęcane dla łatwego rozpoznania typu stacji, kiedy widać sam callsign.
5. Końcówka dokumentu dobija temat: “these are not rigid” oraz “only guidelines to hint at a station's possible application”.
Dlatego przy projektowaniu logiki aplikacji rozdzieliłbym dwie rzeczy: SSID jako operatorski hint oraz capability wynikające z formatu ramek APRS. Ikony / powiadomienie stanu aplikacji są bardzo sensowne jako element UI, ale nie opierałbym ich uzasadnienia na tym, że SSID formalnie definiuje możliwości stacji.
Chodzi mi tylko o jedną rzecz: jeśli sugerujemy rozwiązania do aplikacji, która dekoduje całą ramkę APRS i może odczytać znaczenie poszczególnych pól zgodnie ze specyfikacją, to nie namawiajmy do opierania logiki programu na skrótach myślowych.
SSID może być użyteczną podpowiedzią dla operatora, ale nie powinno zastępować informacji, które aplikacja może odczytać bezpośrednio z ramki.
Czyli: jako człowiek mogę spojrzeć na -9, -7 albo -15 i potraktować to jako pewną sugestię. Natomiast aplikacja, skoro i tak parsuje APRS, powinna korzystać z danych przewidzianych w protokole, a SSID traktować co najwyżej jako dodatkowy, miękki kontekst.
1. Dokument ma tytuł “APRS SSID Recommendations”, a Bob dopisał, że zmieniono tytuł, aby nie sugerować żadnego standardu dekodowania.
2. Pisze wprost, że SSID są obecnie używane jako informal way, czyli nieformalny sposób wskazywania typowych zastosowań APRS.
3. Faktycznie jest tam -9 Primary Mobile (usually message capable) oraz przypis, że -9 zwykle oznacza krótkofalowca w pełnej komunikacji APRS, message plus voice.
4. Ale dalej Bob pisze, że pierwotne skojarzenia SSID nie są już wymaganą częścią specyfikacji, a konwencje są tylko zachęcane dla łatwego rozpoznania typu stacji, kiedy widać sam callsign.
5. Końcówka dokumentu dobija temat: “these are not rigid” oraz “only guidelines to hint at a station's possible application”.
Dlatego przy projektowaniu logiki aplikacji rozdzieliłbym dwie rzeczy: SSID jako operatorski hint oraz capability wynikające z formatu ramek APRS. Ikony / powiadomienie stanu aplikacji są bardzo sensowne jako element UI, ale nie opierałbym ich uzasadnienia na tym, że SSID formalnie definiuje możliwości stacji.
Chodzi mi tylko o jedną rzecz: jeśli sugerujemy rozwiązania do aplikacji, która dekoduje całą ramkę APRS i może odczytać znaczenie poszczególnych pól zgodnie ze specyfikacją, to nie namawiajmy do opierania logiki programu na skrótach myślowych.
SSID może być użyteczną podpowiedzią dla operatora, ale nie powinno zastępować informacji, które aplikacja może odczytać bezpośrednio z ramki.
Czyli: jako człowiek mogę spojrzeć na -9, -7 albo -15 i potraktować to jako pewną sugestię. Natomiast aplikacja, skoro i tak parsuje APRS, powinna korzystać z danych przewidzianych w protokole, a SSID traktować co najwyżej jako dodatkowy, miękki kontekst.