Jump to content

[FEATURE] Hosted GSAK


frinklabs

Recommended Posts

Have Clyde and/or a programming team port GSAK to a version with a web interface.

 

These instances would run on machines in the Groundspeak data centre where the sessions would have direct access to the cache database.

 

An extended version of the API could be offered to these sessions which would include search functionality.

 

File I/O could be done through Dropbox.

 

As a "cloud" version, the software would always be up to date.

 

For this extra functionality I would pay more than what I pay for a single standalone instance of GSAK.

Link to comment

Why aren't you suggesting this to the independent entity that develops that software (except that it would probably violate some section of the TOU)? Groundspeak publishes an API that the software uses - that's the extent of their relationship.

 

I already keep all of my geocaching data on Dropbox, so it's only a matter of having the right software on each of my computers/devices. Not a big challenge.

Edited by dakboy
Link to comment

Why aren't you suggesting this to the independent entity that develops that software (except that it would probably violate some section of the TOU)? Groundspeak publishes an API that the software uses - that's the extent of their relationship.

 

I already keep all of my geocaching data on Dropbox, so it's only a matter of having the right software on each of my computers/devices. Not a big challenge.

 

Search functionality in the API is limited to external apps, as indicated in another suggestion thread ignored by GS: [FEATURE] Extend API functionality to include searching

 

It appears that the official app can search with parameters not available to the open API, presumably because it it is official and they can control what happens.

 

I'd like to see the functionality of GSAK become "official" -- this way they don't have to enhance the existing PQ system to fulfill multiple different requests for it to include other useful parametrization.

 

If I had to guess (and I do -- this is a one-way no-feedback forum) I'd say the limitations on the open API are due to processing or bandwidth issues. Controlling the app-ized hosted version of GSAK would theoretically assuage these concerns.

Link to comment

Why aren't you suggesting this to the independent entity that develops that software (except that it would probably violate some section of the TOU)? Groundspeak publishes an API that the software uses - that's the extent of their relationship.

 

I already keep all of my geocaching data on Dropbox, so it's only a matter of having the right software on each of my computers/devices. Not a big challenge.

 

Search functionality in the API is limited to external apps, as indicated in another suggestion thread ignored by GS: [FEATURE] Extend API functionality to include searching

 

It appears that the official app can search with parameters not available to the open API, presumably because it it is official and they can control what happens.

 

I'd like to see the functionality of GSAK become "official" -- this way they don't have to enhance the existing PQ system to fulfill multiple different requests for it to include other useful parametrization.

 

If I had to guess (and I do -- this is a one-way no-feedback forum) I'd say the limitations on the open API are due to processing or bandwidth issues. Controlling the app-ized hosted version of GSAK would theoretically assuage these concerns.

If you look at GSAK is it a interface to a local SQL database with macro support written in an old Bordeland Delphi version.

To port that to a web version running on a server a complete rewrite has to be done. Even the database structure has to be changes if multiple users should use the same database because of the way your data is stored. And limitations has to be added because som filter options will be slow like advanced regexp search on all cache logs. The direct SQL access is likely that you cant keep because it is to easy to overload the database.

 

The limitation in the API for you to have an updated database in GSAK is not only a processing or bandwidth problem.

The limitation is a oversight or a deliberate chose in the API functions.

It looks to me that the API is designed for uses on a mobile app where you want info on caches around you or info on the cache you look at.

It is not designed to have an update local database.

You can download all logs for a cache but cant ask for logs changed after x so you can update after your last query.

The same for new caches or changes in cache status.

It might be deliberate so it is harder to copy the database.

If changes after parameters was available in the API the database and bandwidth usage would be decreased.

If i what to update all caches in my stat to have to latest cache data i have to refresh all of them and all have to be fetched from the database and sent to me. If i could ask for changes after X the database only have to look at a field with the last time changed and only return caches with changes. That is much less data

 

But i would like som GSAK functionality on the pgc site like adding custom waypoints to caches. It would be nice if i could add all steps in a multicache for future reference on gc.com.

And the option to add custom data to group caches. I can easy in gsak add a field for field pussels, bonus caches and some more and change the name with a script. And easy export that so mysts that are not solved, field pussels, bonuses are not included.

Link to comment

Why aren't you suggesting this to the independent entity that develops that software (except that it would probably violate some section of the TOU)? Groundspeak publishes an API that the software uses - that's the extent of their relationship.

 

I already keep all of my geocaching data on Dropbox, so it's only a matter of having the right software on each of my computers/devices. Not a big challenge.

 

Search functionality in the API is limited to external apps, as indicated in another suggestion thread ignored by GS: [FEATURE] Extend API functionality to include searching

 

It appears that the official app can search with parameters not available to the open API, presumably because it it is official and they can control what happens.

 

I'd like to see the functionality of GSAK become "official" -- this way they don't have to enhance the existing PQ system to fulfill multiple different requests for it to include other useful parametrization.

 

If I had to guess (and I do -- this is a one-way no-feedback forum) I'd say the limitations on the open API are due to processing or bandwidth issues. Controlling the app-ized hosted version of GSAK would theoretically assuage these concerns.

I forgot to ask in my other post what search options are available to the official app? I could find now search options in the app. Only download of caches around a point and local filter on the result but i dont use that app and hav likely missed somthing

Edited by Target.
Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...