| Page 2 of 2 | 1 | 2 |
|
|
A pile of code is not an API, its a pile of code. An API is a designated,
documented interface designed to be stable (in an upwardly-compatible way) over time so that client applications can interact reliably. I'm beginning to think you weren't joking. 73, Dave, AA6YQ "Peter Lemken" wrote in message ... Hank Oredson wrote: 3rd hit. Already have that document. No API specification in that document. OK, Hank, you seem to need spoonfeeding: http://www.trustedqsl.org/ Not very obvious and *very* hard to find. But it has an FAQ. http://cesnet.dl.sourceforge.net/sou...qsllib-doc.zip That's on Sourceforge. You *did* look there, didn't you? Peter Lemken DF5JT Berlin -- Mail an die im From: angegebene Adresse stellt eine Beauftragung zur Überprüfung der Mailfunktion des Absenders dar und wird mit einer Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt. |
Hank Oredson wrote:
I am aware of the architecture, understand how the certificates are used, have my own database and software for dealing with logs, station identification, DX entities, have ADIF reading and writing functions for that database, etc. What I have not yet found is the API into the LotW database, so that I can create my own client to view, modify, delete and insert QSO data. Something like that? |Detailed Description |The Data API is used to form data into TrustedQSL |records. A TrustedQSL record consists of a station record and a QSO |record. Together, the two records fully describe one station's end of the |QSO -- just as a paper QSL card does. I believe this describes the local part of want you want to do with your QSO-data: Forming records, converting and modifying these records and then upload them via the tqsllib. Have I understood you correctly this time? Peter Lemken DF5JT Berlin -- Mail an die im From: angegebene Adresse stellt eine Beauftragung zur Überprüfung der Mailfunktion des Absenders dar und wird mit einer Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt. |
Hank Oredson wrote:
I am aware of the architecture, understand how the certificates are used, have my own database and software for dealing with logs, station identification, DX entities, have ADIF reading and writing functions for that database, etc. What I have not yet found is the API into the LotW database, so that I can create my own client to view, modify, delete and insert QSO data. Something like that? |Detailed Description |The Data API is used to form data into TrustedQSL |records. A TrustedQSL record consists of a station record and a QSO |record. Together, the two records fully describe one station's end of the |QSO -- just as a paper QSL card does. I believe this describes the local part of want you want to do with your QSO-data: Forming records, converting and modifying these records and then upload them via the tqsllib. Have I understood you correctly this time? Peter Lemken DF5JT Berlin -- Mail an die im From: angegebene Adresse stellt eine Beauftragung zur Überprüfung der Mailfunktion des Absenders dar und wird mit einer Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt. |
"Peter Lemken" wrote in message ... Hank Oredson wrote: I am aware of the architecture, understand how the certificates are used, have my own database and software for dealing with logs, station identification, DX entities, have ADIF reading and writing functions for that database, etc. What I have not yet found is the API into the LotW database, so that I can create my own client to view, modify, delete and insert QSO data. Something like that? |Detailed Description |The Data API is used to form data into TrustedQSL |records. A TrustedQSL record consists of a station record and a QSO |record. Together, the two records fully describe one station's end of the |QSO -- just as a paper QSL card does. I believe this describes the local part of want you want to do with your QSO-data: Forming records, converting and modifying these records and then upload them via the tqsllib. Have I understood you correctly this time? Getting closer :-) Here is a description of one application. 1. Connect to the server. This would probably be via HTTP with a cookie to create a session. 2. Authenticate myself to the server. Using my user name and password, and possibly a certificate. 3. Query the server for one or more QSO records. Something that looks like SQL would be most convenient. It should be possible to say "read only" or "for modification". 4. Acquire the records returned by the query. The server must also return status information for each record. 5. View and modify the records locally. Possibly create new records. 6. Return any modified or new records to the server. 7. Acquire status information from the server. 8. Disconnect from the server. I want operations on records, not fields. Things like "tqsl_getLocationDXCCEntity" are simply too low level. What I do not see in tqsllib are the "open database", "get record", "put record", "close database" functions that are needed to build an application. We will see how things work out over time. Perhaps everything I want is actually there, hidden under that huge pile of low level internal function calls. -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
"Peter Lemken" wrote in message ... Hank Oredson wrote: I am aware of the architecture, understand how the certificates are used, have my own database and software for dealing with logs, station identification, DX entities, have ADIF reading and writing functions for that database, etc. What I have not yet found is the API into the LotW database, so that I can create my own client to view, modify, delete and insert QSO data. Something like that? |Detailed Description |The Data API is used to form data into TrustedQSL |records. A TrustedQSL record consists of a station record and a QSO |record. Together, the two records fully describe one station's end of the |QSO -- just as a paper QSL card does. I believe this describes the local part of want you want to do with your QSO-data: Forming records, converting and modifying these records and then upload them via the tqsllib. Have I understood you correctly this time? Getting closer :-) Here is a description of one application. 1. Connect to the server. This would probably be via HTTP with a cookie to create a session. 2. Authenticate myself to the server. Using my user name and password, and possibly a certificate. 3. Query the server for one or more QSO records. Something that looks like SQL would be most convenient. It should be possible to say "read only" or "for modification". 4. Acquire the records returned by the query. The server must also return status information for each record. 5. View and modify the records locally. Possibly create new records. 6. Return any modified or new records to the server. 7. Acquire status information from the server. 8. Disconnect from the server. I want operations on records, not fields. Things like "tqsl_getLocationDXCCEntity" are simply too low level. What I do not see in tqsllib are the "open database", "get record", "put record", "close database" functions that are needed to build an application. We will see how things work out over time. Perhaps everything I want is actually there, hidden under that huge pile of low level internal function calls. -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
Hank Oredson wrote:
I want operations on records, not fields. Things like "tqsl_getLocationDXCCEntity" are simply too low level. Then an API is not what you are looking for, methinks. Peter Lemken DF5JT Berlin -- Mail an die im From: angegebene Adresse stellt eine Beauftragung zur Überprüfung der Mailfunktion des Absenders dar und wird mit einer Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt. |
Hank Oredson wrote:
I want operations on records, not fields. Things like "tqsl_getLocationDXCCEntity" are simply too low level. Then an API is not what you are looking for, methinks. Peter Lemken DF5JT Berlin -- Mail an die im From: angegebene Adresse stellt eine Beauftragung zur Überprüfung der Mailfunktion des Absenders dar und wird mit einer Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt. |
On 1 Oct 2003 16:38:48 GMT, Peter Lemken wrote:
Hank Oredson wrote: I want operations on records, not fields. Things like "tqsl_getLocationDXCCEntity" are simply too low level. Then an API is not what you are looking for, methinks. Peter Lemken DF5JT Berlin - been following this thread... - the ultimate documentation for an application? - the source code! -- Mail an die im From: angegebene Adresse stellt eine Beauftragung zur Überprüfung der Mailfunktion des Absenders dar und wird mit einer Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt. |
On 1 Oct 2003 16:38:48 GMT, Peter Lemken wrote:
Hank Oredson wrote: I want operations on records, not fields. Things like "tqsl_getLocationDXCCEntity" are simply too low level. Then an API is not what you are looking for, methinks. Peter Lemken DF5JT Berlin - been following this thread... - the ultimate documentation for an application? - the source code! -- Mail an die im From: angegebene Adresse stellt eine Beauftragung zur Überprüfung der Mailfunktion des Absenders dar und wird mit einer Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt. |
wrote in message ... On 1 Oct 2003 16:38:48 GMT, Peter Lemken wrote: Hank Oredson wrote: I want operations on records, not fields. Things like "tqsl_getLocationDXCCEntity" are simply too low level. Then an API is not what you are looking for, methinks. Peter Lemken DF5JT Berlin - been following this thread... - the ultimate documentation for an application? There is NO such application. - the source code! Pretty hard to look at source code that does not exist. -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
wrote in message ... On 1 Oct 2003 16:38:48 GMT, Peter Lemken wrote: Hank Oredson wrote: I want operations on records, not fields. Things like "tqsl_getLocationDXCCEntity" are simply too low level. Then an API is not what you are looking for, methinks. Peter Lemken DF5JT Berlin - been following this thread... - the ultimate documentation for an application? There is NO such application. - the source code! Pretty hard to look at source code that does not exist. -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
Hank,
When installing TQSL-108.EXE you get TQSLLIB.DLL. I didn't analyze yet but I guess the API calls could be made through that DLL. Then you got TQSLLIB-1.3.TAR.GZ which includes a lot of C++ source code and documentation. Maybe it could be useable. I did not yet really have time to look through it but I think it would a starting point for available functions and descriptions. 73 |
Hank,
When installing TQSL-108.EXE you get TQSLLIB.DLL. I didn't analyze yet but I guess the API calls could be made through that DLL. Then you got TQSLLIB-1.3.TAR.GZ which includes a lot of C++ source code and documentation. Maybe it could be useable. I did not yet really have time to look through it but I think it would a starting point for available functions and descriptions. 73 |
"ranger" wrote in message ... Hank, When installing TQSL-108.EXE you get TQSLLIB.DLL. I didn't analyze yet but I guess the API calls could be made through that DLL. Then you got TQSLLIB-1.3.TAR.GZ which includes a lot of C++ source code and documentation. Maybe it could be useable. I did not yet really have time to look through it but I think it would a starting point for available functions and descriptions. See my other posts. I have those things. There is no API to the database. -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
"ranger" wrote in message ... Hank, When installing TQSL-108.EXE you get TQSLLIB.DLL. I didn't analyze yet but I guess the API calls could be made through that DLL. Then you got TQSLLIB-1.3.TAR.GZ which includes a lot of C++ source code and documentation. Maybe it could be useable. I did not yet really have time to look through it but I think it would a starting point for available functions and descriptions. See my other posts. I have those things. There is no API to the database. -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
Hank Oredson wrote:
"ranger" wrote in message ... Hank, When installing TQSL-108.EXE you get TQSLLIB.DLL. I didn't analyze yet but I guess the API calls could be made through that DLL. Then you got TQSLLIB-1.3.TAR.GZ which includes a lot of C++ source code and documentation. Maybe it could be useable. I did not yet really have time to look through it but I think it would a starting point for available functions and descriptions. See my other posts. I have those things. There is no API to the database. Yes, there is, Hank. API stands for "Advanced Programming Interface" and it describes the programming interface to a lower layer that you can use. The README states "API documentation can be found in the doxygen directory." peter@sassicaia tqsllib $ tar tzf /home/downloads/src/tqsllib-1.3.tar.gz |grep doxygen tqsllib/doxygen/html/ tqsllib/doxygen/html/doxygen.gif tqsllib/doxygen/html/tqsllib.css tqsllib/doxygen/html/index.html tqsllib/doxygen/html/files.html tqsllib/doxygen/html/adif_8h-source.html tqsllib/doxygen/html/cabrillo_8h-source.html tqsllib/doxygen/html/tqslconvert_8h-source.html tqsllib/doxygen/html/tqslerrno_8h-source.html tqsllib/doxygen/html/tqsllib-doc_8h-source.html tqsllib/doxygen/html/tqsllib_8h-source.html tqsllib/doxygen/html/tqslconvert_8h.html tqsllib/doxygen/html/tqslerrno_8h.html tqsllib/doxygen/html/tqsllib_8h.html tqsllib/doxygen/html/annotated.html tqsllib/doxygen/html/structtqsl__adifFieldDefinitions.html tqsllib/doxygen/html/structtqsl__adifFieldDefinitions-members.html tqsllib/doxygen/html/structtqsl__adifFieldResults.html tqsllib/doxygen/html/structtqsl__adifFieldResults-members.html tqsllib/doxygen/html/structtqsl__cabrilloField.html tqsllib/doxygen/html/structtqsl__cabrilloField-members.html tqsllib/doxygen/html/structtqsl__cert__req__st.html tqsllib/doxygen/html/structtqsl__cert__req__st-members.html tqsllib/doxygen/html/structtQSL__Date.html tqsllib/doxygen/html/structtQSL__Date-members.html tqsllib/doxygen/html/structtqsl__provider__st.html tqsllib/doxygen/html/structtqsl__provider__st-members.html tqsllib/doxygen/html/structTQSL__QSO__RECORD.html tqsllib/doxygen/html/structTQSL__QSO__RECORD-members.html tqsllib/doxygen/html/structtQSL__Time.html tqsllib/doxygen/html/structtQSL__Time-members.html tqsllib/doxygen/html/group__Util.html tqsllib/doxygen/html/group__CertStuff.html tqsllib/doxygen/html/group__Sign.html tqsllib/doxygen/html/group__Data.html tqsllib/doxygen/html/group__ADIF.html tqsllib/doxygen/html/group__Cabrillo.html tqsllib/doxygen/html/group__Convert.html tqsllib/doxygen/html/modules.html tqsllib/doxygen/html/globals.html peter@sassicaia tqsllib The API is right there, it's documented, it's usable. Obviously, what you are looking for is an _application_ that performs certain tasks to your liking. That's not what an API does, you need to write an application that makes use of the API. Apart from that: This is an Open Source project, so you can contribute your patches and express dissatisfaction with what's currently available. However, please refrain from telling us "There is no API". There is, Hank, and I told you where it is about a week ago. Peter Lemken DF5JT Berlin -- Mail an die im From: angegebene Adresse stellt eine Beauftragung zur Überprüfung der Mailfunktion des Absenders dar und wird mit einer Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt. |
Hank Oredson wrote:
"ranger" wrote in message ... Hank, When installing TQSL-108.EXE you get TQSLLIB.DLL. I didn't analyze yet but I guess the API calls could be made through that DLL. Then you got TQSLLIB-1.3.TAR.GZ which includes a lot of C++ source code and documentation. Maybe it could be useable. I did not yet really have time to look through it but I think it would a starting point for available functions and descriptions. See my other posts. I have those things. There is no API to the database. Yes, there is, Hank. API stands for "Advanced Programming Interface" and it describes the programming interface to a lower layer that you can use. The README states "API documentation can be found in the doxygen directory." peter@sassicaia tqsllib $ tar tzf /home/downloads/src/tqsllib-1.3.tar.gz |grep doxygen tqsllib/doxygen/html/ tqsllib/doxygen/html/doxygen.gif tqsllib/doxygen/html/tqsllib.css tqsllib/doxygen/html/index.html tqsllib/doxygen/html/files.html tqsllib/doxygen/html/adif_8h-source.html tqsllib/doxygen/html/cabrillo_8h-source.html tqsllib/doxygen/html/tqslconvert_8h-source.html tqsllib/doxygen/html/tqslerrno_8h-source.html tqsllib/doxygen/html/tqsllib-doc_8h-source.html tqsllib/doxygen/html/tqsllib_8h-source.html tqsllib/doxygen/html/tqslconvert_8h.html tqsllib/doxygen/html/tqslerrno_8h.html tqsllib/doxygen/html/tqsllib_8h.html tqsllib/doxygen/html/annotated.html tqsllib/doxygen/html/structtqsl__adifFieldDefinitions.html tqsllib/doxygen/html/structtqsl__adifFieldDefinitions-members.html tqsllib/doxygen/html/structtqsl__adifFieldResults.html tqsllib/doxygen/html/structtqsl__adifFieldResults-members.html tqsllib/doxygen/html/structtqsl__cabrilloField.html tqsllib/doxygen/html/structtqsl__cabrilloField-members.html tqsllib/doxygen/html/structtqsl__cert__req__st.html tqsllib/doxygen/html/structtqsl__cert__req__st-members.html tqsllib/doxygen/html/structtQSL__Date.html tqsllib/doxygen/html/structtQSL__Date-members.html tqsllib/doxygen/html/structtqsl__provider__st.html tqsllib/doxygen/html/structtqsl__provider__st-members.html tqsllib/doxygen/html/structTQSL__QSO__RECORD.html tqsllib/doxygen/html/structTQSL__QSO__RECORD-members.html tqsllib/doxygen/html/structtQSL__Time.html tqsllib/doxygen/html/structtQSL__Time-members.html tqsllib/doxygen/html/group__Util.html tqsllib/doxygen/html/group__CertStuff.html tqsllib/doxygen/html/group__Sign.html tqsllib/doxygen/html/group__Data.html tqsllib/doxygen/html/group__ADIF.html tqsllib/doxygen/html/group__Cabrillo.html tqsllib/doxygen/html/group__Convert.html tqsllib/doxygen/html/modules.html tqsllib/doxygen/html/globals.html peter@sassicaia tqsllib The API is right there, it's documented, it's usable. Obviously, what you are looking for is an _application_ that performs certain tasks to your liking. That's not what an API does, you need to write an application that makes use of the API. Apart from that: This is an Open Source project, so you can contribute your patches and express dissatisfaction with what's currently available. However, please refrain from telling us "There is no API". There is, Hank, and I told you where it is about a week ago. Peter Lemken DF5JT Berlin -- Mail an die im From: angegebene Adresse stellt eine Beauftragung zur Überprüfung der Mailfunktion des Absenders dar und wird mit einer Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt. |
"Peter Lemken" wrote in message ... Hank Oredson wrote: "ranger" wrote in message ... Hank, When installing TQSL-108.EXE you get TQSLLIB.DLL. I didn't analyze yet but I guess the API calls could be made through that DLL. Then you got TQSLLIB-1.3.TAR.GZ which includes a lot of C++ source code and documentation. Maybe it could be useable. I did not yet really have time to look through it but I think it would a starting point for available functions and descriptions. See my other posts. I have those things. There is no API to the database. Yes, there is, Hank. API stands for "Advanced Programming Interface" and it describes the programming interface to a lower layer that you can use. "Application programming interface." "... TO THE DATABASE." The API is right there, it's documented, it's usable. There is NO API TO THE DATABASE. This should be very very simple to understand. What you show me is a set of library calls for manipulating LOCAL DATA and LOCAL FILES. This is not of interest. Obviously, what you are looking for is an _application_ that performs certain tasks to your liking. That's not what an API does, you need to write an application that makes use of the API. I am not looking for an application. I WRITE APPLICATIONS. To do this, I NEED THE SPECIFICATION. IF I have the specification ... see below ... Apart from that: This is an Open Source project, so you can contribute your patches and express dissatisfaction with what's currently available. There is NOTHING available. There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE. None, zero, nichts, nada. Were there such a specification, I would CREATE a library of functions and gladly donate it to the project. Then there would be an API to the DATABASE, and everyone could use it. Please try very very hard to understand what I have written. LotW is a CENTRALIZED DATABASE of QSO data. I wish to access it. From applications I will write. For eQSL, I can do these things. There is an API, it is documented. LotW is still in it's baby steps, perhaps like a very early prototype. -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
"Peter Lemken" wrote in message ... Hank Oredson wrote: "ranger" wrote in message ... Hank, When installing TQSL-108.EXE you get TQSLLIB.DLL. I didn't analyze yet but I guess the API calls could be made through that DLL. Then you got TQSLLIB-1.3.TAR.GZ which includes a lot of C++ source code and documentation. Maybe it could be useable. I did not yet really have time to look through it but I think it would a starting point for available functions and descriptions. See my other posts. I have those things. There is no API to the database. Yes, there is, Hank. API stands for "Advanced Programming Interface" and it describes the programming interface to a lower layer that you can use. "Application programming interface." "... TO THE DATABASE." The API is right there, it's documented, it's usable. There is NO API TO THE DATABASE. This should be very very simple to understand. What you show me is a set of library calls for manipulating LOCAL DATA and LOCAL FILES. This is not of interest. Obviously, what you are looking for is an _application_ that performs certain tasks to your liking. That's not what an API does, you need to write an application that makes use of the API. I am not looking for an application. I WRITE APPLICATIONS. To do this, I NEED THE SPECIFICATION. IF I have the specification ... see below ... Apart from that: This is an Open Source project, so you can contribute your patches and express dissatisfaction with what's currently available. There is NOTHING available. There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE. None, zero, nichts, nada. Were there such a specification, I would CREATE a library of functions and gladly donate it to the project. Then there would be an API to the DATABASE, and everyone could use it. Please try very very hard to understand what I have written. LotW is a CENTRALIZED DATABASE of QSO data. I wish to access it. From applications I will write. For eQSL, I can do these things. There is an API, it is documented. LotW is still in it's baby steps, perhaps like a very early prototype. -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
Hank Oredson wrote:
"Peter Lemken" wrote in message Yes, there is, Hank. API stands for "Advanced Programming Interface" and it describes the programming interface to a lower layer that you can use. "Application programming interface." "... TO THE DATABASE." The Central Database of the arrl lotw project? The API is right there, it's documented, it's usable. There is NO API TO THE DATABASE. I am still not sure you are talking about the database I had in mind. This should be very very simple to understand. What you show me is a set of library calls for manipulating LOCAL DATA and LOCAL FILES. This is not of interest. Yes, it is, at least for log programmers. Prepare the data in an accepted form, sign it digitally with your unique key and hold personal responsibility for the integrity of the data. And that is done locally by a log program. Am I still with you? Obviously, what you are looking for is an _application_ that performs certain tasks to your liking. That's not what an API does, you need to write an application that makes use of the API. I am not looking for an application. I WRITE APPLICATIONS. What kind of applications? Logbooks? To do this, I NEED THE SPECIFICATION. IF I have the specification ... see below ... Apart from that: This is an Open Source project, so you can contribute your patches and express dissatisfaction with what's currently available. There is NOTHING available. There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE. None, zero, nichts, nada. Were there such a specification, I would CREATE a library of functions and gladly donate it to the project. Then there would be an API to the DATABASE, and everyone could use it. Please try very very hard to understand what I have written. LotW is a CENTRALIZED DATABASE of QSO data. I wish to access it. From applications I will write. What you want is restricted remote access to another machine in order to manipulate data (QSO-records). Have I understood you correctly? For eQSL, I can do these things. There is an API, it is documented. LotW is still in it's baby steps, perhaps like a very early prototype. I'm gonna refer to that once you tell me whether I have understood you correctly about the central database of the ARRL. Peter Lemken DF5JT Berlin -- Mail an die im From: angegebene Adresse stellt eine Beauftragung zur Überprüfung der Mailfunktion des Absenders dar und wird mit einer Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt. |
Hank Oredson wrote:
"Peter Lemken" wrote in message Yes, there is, Hank. API stands for "Advanced Programming Interface" and it describes the programming interface to a lower layer that you can use. "Application programming interface." "... TO THE DATABASE." The Central Database of the arrl lotw project? The API is right there, it's documented, it's usable. There is NO API TO THE DATABASE. I am still not sure you are talking about the database I had in mind. This should be very very simple to understand. What you show me is a set of library calls for manipulating LOCAL DATA and LOCAL FILES. This is not of interest. Yes, it is, at least for log programmers. Prepare the data in an accepted form, sign it digitally with your unique key and hold personal responsibility for the integrity of the data. And that is done locally by a log program. Am I still with you? Obviously, what you are looking for is an _application_ that performs certain tasks to your liking. That's not what an API does, you need to write an application that makes use of the API. I am not looking for an application. I WRITE APPLICATIONS. What kind of applications? Logbooks? To do this, I NEED THE SPECIFICATION. IF I have the specification ... see below ... Apart from that: This is an Open Source project, so you can contribute your patches and express dissatisfaction with what's currently available. There is NOTHING available. There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE. None, zero, nichts, nada. Were there such a specification, I would CREATE a library of functions and gladly donate it to the project. Then there would be an API to the DATABASE, and everyone could use it. Please try very very hard to understand what I have written. LotW is a CENTRALIZED DATABASE of QSO data. I wish to access it. From applications I will write. What you want is restricted remote access to another machine in order to manipulate data (QSO-records). Have I understood you correctly? For eQSL, I can do these things. There is an API, it is documented. LotW is still in it's baby steps, perhaps like a very early prototype. I'm gonna refer to that once you tell me whether I have understood you correctly about the central database of the ARRL. Peter Lemken DF5JT Berlin -- Mail an die im From: angegebene Adresse stellt eine Beauftragung zur Überprüfung der Mailfunktion des Absenders dar und wird mit einer Bearbeitungsgebühr von EUR 1000,- in Rechnung gestellt. |
"Peter Lemken" wrote in message ... Hank Oredson wrote: "Peter Lemken" wrote in message Yes, there is, Hank. API stands for "Advanced Programming Interface" and it describes the programming interface to a lower layer that you can use. "Application programming interface." "... TO THE DATABASE." The Central Database of the arrl lotw project? Yes. The API is right there, it's documented, it's usable. There is NO API TO THE DATABASE. I am still not sure you are talking about the database I had in mind. This should be very very simple to understand. What you show me is a set of library calls for manipulating LOCAL DATA and LOCAL FILES. This is not of interest. Yes, it is, at least for log programmers. Prepare the data in an accepted form, sign it digitally with your unique key and hold personal responsibility for the integrity of the data. And that is done locally by a log program. Am I still with you? Yes. Obviously, what you are looking for is an _application_ that performs certain tasks to your liking. That's not what an API does, you need to write an application that makes use of the API. I am not looking for an application. I WRITE APPLICATIONS. What kind of applications? Logbooks? Logbook and log archive are of interest here of course. What kind of applications do I write? Many ;-) To do this, I NEED THE SPECIFICATION. IF I have the specification ... see below ... Apart from that: This is an Open Source project, so you can contribute your patches and express dissatisfaction with what's currently available. There is NOTHING available. There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE. None, zero, nichts, nada. Were there such a specification, I would CREATE a library of functions and gladly donate it to the project. Then there would be an API to the DATABASE, and everyone could use it. Please try very very hard to understand what I have written. LotW is a CENTRALIZED DATABASE of QSO data. I wish to access it. From applications I will write. What you want is restricted remote access to another machine in order to manipulate data (QSO-records). Have I understood you correctly? Yes. Exactly. Realtime access to the database. With the same security as any other access, via certificate and signing. For eQSL, I can do these things. There is an API, it is documented. LotW is still in it's baby steps, perhaps like a very early prototype. I'm gonna refer to that once you tell me whether I have understood you correctly about the central database of the ARRL. Yes, the one and only LotW database. Where the QSO and QSL information is located. Online access to that database. Right now access is via file upload (or email) to put data INTO the database, and is via HTTP to get data OUT of the database. I could reverse engineer that process and use it. But it seems better to have a documented and supported API. As I mentioned before, this API might be ONLY a protocol specification, with NO code (libraries) involved. What I'm talking about is different than the issue of signing the data. That is already handled by the tQSL library. I don't like the way the library is organized (too low level and complex), but that is not a problem since I can put my own wrapper on top of what exists to make reasonable functions. Mostly I discuss these ideas because I think it is important for LotW to do much much more than it does now. If it does not, people will not integrate it into their applications, it will not be used, and the project will fail. The existing prototype of LotW does not seem to me very useful. Perhaps that will change. There are other competing "global ham radio QSO" databases. Eventually these databases will need to be linked for them to be useful. It is not clear that LotW has a chance. Were the LotW team work with others (e.g. eQSL) progress might occur faster. I step down from my soapbox now. Sorry for delay in this response, took a few minutes away from the computer to work 3C0V on 15M ... -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
"Peter Lemken" wrote in message ... Hank Oredson wrote: "Peter Lemken" wrote in message Yes, there is, Hank. API stands for "Advanced Programming Interface" and it describes the programming interface to a lower layer that you can use. "Application programming interface." "... TO THE DATABASE." The Central Database of the arrl lotw project? Yes. The API is right there, it's documented, it's usable. There is NO API TO THE DATABASE. I am still not sure you are talking about the database I had in mind. This should be very very simple to understand. What you show me is a set of library calls for manipulating LOCAL DATA and LOCAL FILES. This is not of interest. Yes, it is, at least for log programmers. Prepare the data in an accepted form, sign it digitally with your unique key and hold personal responsibility for the integrity of the data. And that is done locally by a log program. Am I still with you? Yes. Obviously, what you are looking for is an _application_ that performs certain tasks to your liking. That's not what an API does, you need to write an application that makes use of the API. I am not looking for an application. I WRITE APPLICATIONS. What kind of applications? Logbooks? Logbook and log archive are of interest here of course. What kind of applications do I write? Many ;-) To do this, I NEED THE SPECIFICATION. IF I have the specification ... see below ... Apart from that: This is an Open Source project, so you can contribute your patches and express dissatisfaction with what's currently available. There is NOTHING available. There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE. None, zero, nichts, nada. Were there such a specification, I would CREATE a library of functions and gladly donate it to the project. Then there would be an API to the DATABASE, and everyone could use it. Please try very very hard to understand what I have written. LotW is a CENTRALIZED DATABASE of QSO data. I wish to access it. From applications I will write. What you want is restricted remote access to another machine in order to manipulate data (QSO-records). Have I understood you correctly? Yes. Exactly. Realtime access to the database. With the same security as any other access, via certificate and signing. For eQSL, I can do these things. There is an API, it is documented. LotW is still in it's baby steps, perhaps like a very early prototype. I'm gonna refer to that once you tell me whether I have understood you correctly about the central database of the ARRL. Yes, the one and only LotW database. Where the QSO and QSL information is located. Online access to that database. Right now access is via file upload (or email) to put data INTO the database, and is via HTTP to get data OUT of the database. I could reverse engineer that process and use it. But it seems better to have a documented and supported API. As I mentioned before, this API might be ONLY a protocol specification, with NO code (libraries) involved. What I'm talking about is different than the issue of signing the data. That is already handled by the tQSL library. I don't like the way the library is organized (too low level and complex), but that is not a problem since I can put my own wrapper on top of what exists to make reasonable functions. Mostly I discuss these ideas because I think it is important for LotW to do much much more than it does now. If it does not, people will not integrate it into their applications, it will not be used, and the project will fail. The existing prototype of LotW does not seem to me very useful. Perhaps that will change. There are other competing "global ham radio QSO" databases. Eventually these databases will need to be linked for them to be useful. It is not clear that LotW has a chance. Were the LotW team work with others (e.g. eQSL) progress might occur faster. I step down from my soapbox now. Sorry for delay in this response, took a few minutes away from the computer to work 3C0V on 15M ... -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
Just to make Hank's point concrete:
One can today export ADIF from a logging application and upload that ADIF to LOTW. However, it is not possible to write an application that can determine which of the QSOs in that uploaded ADIF were accepted by LOTW (as opposed to rejected for a host of possible reasons). Furthermore, it is not possible to write an application that can determine which of the QSOs accepted by LOTW have been "matched" by LOTW and thus considered confirmed. If a user wishes his or her logging application to accurately reflect the status shown on the LOTW web page, that user must manually update the logging application, QSO by QSO. This situation exists because there is no documented API that provides access to information in the LOTW database. The access required is read-only; the fact that the database is centralized is not an obstacle to the provision of a client API. I have discussed these points months ago with Jon KE3Z (LOTW project manager) on the Trusted QSL reflector, and he acknowledged an intent to provide such a mechanism; the relevant messages are http://groups.yahoo.com/group/TrustedQSL/message/240 and http://groups.yahoo.com/group/TrustedQSL/message/246 . My understanding is that the LOTW team has higher priorities right now. In my view, an API should have been provided prior to beta test; waiting until after production release to implement such functionality is highly risky. That, however, is where we are. Lets just hope this functionality isn't permanently triaged. Pressure from the user community wouldn't hurt. 73, Dave, AA6YQ "Hank Oredson" wrote in message ... "Peter Lemken" wrote in message ... Hank Oredson wrote: "Peter Lemken" wrote in message Yes, there is, Hank. API stands for "Advanced Programming Interface" and it describes the programming interface to a lower layer that you can use. "Application programming interface." "... TO THE DATABASE." The Central Database of the arrl lotw project? Yes. The API is right there, it's documented, it's usable. There is NO API TO THE DATABASE. I am still not sure you are talking about the database I had in mind. This should be very very simple to understand. What you show me is a set of library calls for manipulating LOCAL DATA and LOCAL FILES. This is not of interest. Yes, it is, at least for log programmers. Prepare the data in an accepted form, sign it digitally with your unique key and hold personal responsibility for the integrity of the data. And that is done locally by a log program. Am I still with you? Yes. Obviously, what you are looking for is an _application_ that performs certain tasks to your liking. That's not what an API does, you need to write an application that makes use of the API. I am not looking for an application. I WRITE APPLICATIONS. What kind of applications? Logbooks? Logbook and log archive are of interest here of course. What kind of applications do I write? Many ;-) To do this, I NEED THE SPECIFICATION. IF I have the specification ... see below ... Apart from that: This is an Open Source project, so you can contribute your patches and express dissatisfaction with what's currently available. There is NOTHING available. There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE. None, zero, nichts, nada. Were there such a specification, I would CREATE a library of functions and gladly donate it to the project. Then there would be an API to the DATABASE, and everyone could use it. Please try very very hard to understand what I have written. LotW is a CENTRALIZED DATABASE of QSO data. I wish to access it. From applications I will write. What you want is restricted remote access to another machine in order to manipulate data (QSO-records). Have I understood you correctly? Yes. Exactly. Realtime access to the database. With the same security as any other access, via certificate and signing. For eQSL, I can do these things. There is an API, it is documented. LotW is still in it's baby steps, perhaps like a very early prototype. I'm gonna refer to that once you tell me whether I have understood you correctly about the central database of the ARRL. Yes, the one and only LotW database. Where the QSO and QSL information is located. Online access to that database. Right now access is via file upload (or email) to put data INTO the database, and is via HTTP to get data OUT of the database. I could reverse engineer that process and use it. But it seems better to have a documented and supported API. As I mentioned before, this API might be ONLY a protocol specification, with NO code (libraries) involved. What I'm talking about is different than the issue of signing the data. That is already handled by the tQSL library. I don't like the way the library is organized (too low level and complex), but that is not a problem since I can put my own wrapper on top of what exists to make reasonable functions. Mostly I discuss these ideas because I think it is important for LotW to do much much more than it does now. If it does not, people will not integrate it into their applications, it will not be used, and the project will fail. The existing prototype of LotW does not seem to me very useful. Perhaps that will change. There are other competing "global ham radio QSO" databases. Eventually these databases will need to be linked for them to be useful. It is not clear that LotW has a chance. Were the LotW team work with others (e.g. eQSL) progress might occur faster. I step down from my soapbox now. Sorry for delay in this response, took a few minutes away from the computer to work 3C0V on 15M ... -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
Just to make Hank's point concrete:
One can today export ADIF from a logging application and upload that ADIF to LOTW. However, it is not possible to write an application that can determine which of the QSOs in that uploaded ADIF were accepted by LOTW (as opposed to rejected for a host of possible reasons). Furthermore, it is not possible to write an application that can determine which of the QSOs accepted by LOTW have been "matched" by LOTW and thus considered confirmed. If a user wishes his or her logging application to accurately reflect the status shown on the LOTW web page, that user must manually update the logging application, QSO by QSO. This situation exists because there is no documented API that provides access to information in the LOTW database. The access required is read-only; the fact that the database is centralized is not an obstacle to the provision of a client API. I have discussed these points months ago with Jon KE3Z (LOTW project manager) on the Trusted QSL reflector, and he acknowledged an intent to provide such a mechanism; the relevant messages are http://groups.yahoo.com/group/TrustedQSL/message/240 and http://groups.yahoo.com/group/TrustedQSL/message/246 . My understanding is that the LOTW team has higher priorities right now. In my view, an API should have been provided prior to beta test; waiting until after production release to implement such functionality is highly risky. That, however, is where we are. Lets just hope this functionality isn't permanently triaged. Pressure from the user community wouldn't hurt. 73, Dave, AA6YQ "Hank Oredson" wrote in message ... "Peter Lemken" wrote in message ... Hank Oredson wrote: "Peter Lemken" wrote in message Yes, there is, Hank. API stands for "Advanced Programming Interface" and it describes the programming interface to a lower layer that you can use. "Application programming interface." "... TO THE DATABASE." The Central Database of the arrl lotw project? Yes. The API is right there, it's documented, it's usable. There is NO API TO THE DATABASE. I am still not sure you are talking about the database I had in mind. This should be very very simple to understand. What you show me is a set of library calls for manipulating LOCAL DATA and LOCAL FILES. This is not of interest. Yes, it is, at least for log programmers. Prepare the data in an accepted form, sign it digitally with your unique key and hold personal responsibility for the integrity of the data. And that is done locally by a log program. Am I still with you? Yes. Obviously, what you are looking for is an _application_ that performs certain tasks to your liking. That's not what an API does, you need to write an application that makes use of the API. I am not looking for an application. I WRITE APPLICATIONS. What kind of applications? Logbooks? Logbook and log archive are of interest here of course. What kind of applications do I write? Many ;-) To do this, I NEED THE SPECIFICATION. IF I have the specification ... see below ... Apart from that: This is an Open Source project, so you can contribute your patches and express dissatisfaction with what's currently available. There is NOTHING available. There is NO SPECIFICATION of HOW TO ACCESS THE DATABASE. None, zero, nichts, nada. Were there such a specification, I would CREATE a library of functions and gladly donate it to the project. Then there would be an API to the DATABASE, and everyone could use it. Please try very very hard to understand what I have written. LotW is a CENTRALIZED DATABASE of QSO data. I wish to access it. From applications I will write. What you want is restricted remote access to another machine in order to manipulate data (QSO-records). Have I understood you correctly? Yes. Exactly. Realtime access to the database. With the same security as any other access, via certificate and signing. For eQSL, I can do these things. There is an API, it is documented. LotW is still in it's baby steps, perhaps like a very early prototype. I'm gonna refer to that once you tell me whether I have understood you correctly about the central database of the ARRL. Yes, the one and only LotW database. Where the QSO and QSL information is located. Online access to that database. Right now access is via file upload (or email) to put data INTO the database, and is via HTTP to get data OUT of the database. I could reverse engineer that process and use it. But it seems better to have a documented and supported API. As I mentioned before, this API might be ONLY a protocol specification, with NO code (libraries) involved. What I'm talking about is different than the issue of signing the data. That is already handled by the tQSL library. I don't like the way the library is organized (too low level and complex), but that is not a problem since I can put my own wrapper on top of what exists to make reasonable functions. Mostly I discuss these ideas because I think it is important for LotW to do much much more than it does now. If it does not, people will not integrate it into their applications, it will not be used, and the project will fail. The existing prototype of LotW does not seem to me very useful. Perhaps that will change. There are other competing "global ham radio QSO" databases. Eventually these databases will need to be linked for them to be useful. It is not clear that LotW has a chance. Were the LotW team work with others (e.g. eQSL) progress might occur faster. I step down from my soapbox now. Sorry for delay in this response, took a few minutes away from the computer to work 3C0V on 15M ... -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
On Fri, 03 Oct 2003 22:01:53 GMT, "Hank Oredson"
wrote: Please try very very hard to understand what I have written. LotW is a CENTRALIZED DATABASE of QSO data. I wish to access it. From applications I will write. You can't do that unless your ISP has DSL modems with a quarter slot in the top...... Not to mention it wouldn't be "secure" if you knew who I worked. Maybe I worked you and you didn't know it, so you could then apply for credit for working me even though you didn't know you did. (work me) LOTW is much more complicated that it really appears to be..... Please try very hard to understand what the ARRL has written. Software for collecting quarters...... Cha Ching....... 73, Jim KH2D |
On Fri, 03 Oct 2003 22:01:53 GMT, "Hank Oredson"
wrote: Please try very very hard to understand what I have written. LotW is a CENTRALIZED DATABASE of QSO data. I wish to access it. From applications I will write. You can't do that unless your ISP has DSL modems with a quarter slot in the top...... Not to mention it wouldn't be "secure" if you knew who I worked. Maybe I worked you and you didn't know it, so you could then apply for credit for working me even though you didn't know you did. (work me) LOTW is much more complicated that it really appears to be..... Please try very hard to understand what the ARRL has written. Software for collecting quarters...... Cha Ching....... 73, Jim KH2D |
wrote in message .. . On Fri, 03 Oct 2003 22:01:53 GMT, "Hank Oredson" wrote: Please try very very hard to understand what I have written. LotW is a CENTRALIZED DATABASE of QSO data. I wish to access it. From applications I will write. You can't do that unless your ISP has DSL modems with a quarter slot in the top...... Why? I can access my QSO data via the web page for no charge. Not to mention it wouldn't be "secure" if you knew who I worked. Why? I can only access my own QSO data. Maybe I worked you and you didn't know it, so you could then apply for credit for working me even though you didn't know you did. (work me) For this part of the discussion, and for the API of interest, awards do not come into play. Only my own QSO data. LOTW is much more complicated that it really appears to be..... Naw, I think it is less complex than it appears :-) Please try very hard to understand what the ARRL has written. Oh I do understand! Software for collecting quarters...... Cha Ching....... That is the ARRL view of their database. My view is different, since I do not care about the awards. -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
wrote in message .. . On Fri, 03 Oct 2003 22:01:53 GMT, "Hank Oredson" wrote: Please try very very hard to understand what I have written. LotW is a CENTRALIZED DATABASE of QSO data. I wish to access it. From applications I will write. You can't do that unless your ISP has DSL modems with a quarter slot in the top...... Why? I can access my QSO data via the web page for no charge. Not to mention it wouldn't be "secure" if you knew who I worked. Why? I can only access my own QSO data. Maybe I worked you and you didn't know it, so you could then apply for credit for working me even though you didn't know you did. (work me) For this part of the discussion, and for the API of interest, awards do not come into play. Only my own QSO data. LOTW is much more complicated that it really appears to be..... Naw, I think it is less complex than it appears :-) Please try very hard to understand what the ARRL has written. Oh I do understand! Software for collecting quarters...... Cha Ching....... That is the ARRL view of their database. My view is different, since I do not care about the awards. -- ... Hank Hank: http://horedson.home.att.net W0RLI: http://w0rli.home.att.net |
| All times are GMT +1. The time now is 01:54 AM. |
|
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
RadioBanter.com