Home |
Search |
Today's Posts |
#61
![]() |
|||
|
|||
![]()
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. |
#62
![]() |
|||
|
|||
![]() "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 |
#63
![]() |
|||
|
|||
![]() "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 |
#64
![]() |
|||
|
|||
![]()
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 |
#65
![]() |
|||
|
|||
![]()
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 |
#66
![]() |
|||
|
|||
![]()
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 |
#67
![]() |
|||
|
|||
![]()
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 |
#68
![]() |
|||
|
|||
![]() 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 |
#69
![]() |
|||
|
|||
![]() 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 |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|