Is OKAPI still a common API for all opencaching platforms? Is it still actively maintained?

[hxdimpf]

The plaftorms supported by OKAPI have diverged over the last 5 years. New functionality has been added to specific platforms, for instance, for OCDE there is:

• List support
• Draft log support

This functionality should be made available to client applications via OKAPI. I have developed a set of PRs which do exactly this, however, I haven't found anybody who feels in charge of conducting a review and then hopefully merge the PRs and make a new release available to the platforms. @wrygiel has done some initial reviewing for one of my three PRs, however, he says he is no longer on the project and he is not the one doing merges and not the one doing releases.

Looking at the last few merges, I am relaying this issue to @kojoty and @deg-pl, do you guys feel in charge? Who is the official maintainer of this repo? Please take the time and comment on your view of the future of OKAPI.

[wrygiel]

Pasting my response to your last email here too, for more context (might help with the discussion with OCPL and OCDE):

You are not the one who makes releases

When I was last working on the project, OCPL releases were automated, OCDE needed some work on OCDE side.

You are not the one who merges PRs

I am one of the people who still have access to merge PRs, but it's not a regular task of mine. (I haven't played with geocaching for many years now.)

You are not the one who can afford the time to thoroughly review PRs (the time you spent is very very much appreciated and was of great help to me, thx much again!)

Yes, that's correct. I can still approve small, simple CLs, if you are fine with waiting 1-2 weeks.

The OKAPI repo is functionally stabilized as there have been only a handful of commits in the last 4 years. There is an umerged PR in the pipe since 2019. There seems to be a maintainer but he has not been reacted to mails in months. You conisder that a temporary situation, I must say, I have little confidence that this will change. If it does, then that is good and I will collaborate to the best I am capable of.

It has already changed in the past. We had 2 other regular maintainers during the last couple of years, but they also left their post. That's why I say it might be temporary, as another maintainer might show up.

The platforms have diverged substantially over time, some platforms, for instance OCDE has developed new functionality such as List support and Draft logs while others have not. The new functions have never been made available to client applications via OKAPI, which is why I come to the conclusion in (4). Consequently, I am adding new functionality which cannot have a compatible OCPL branch as the functionality doesn't exist there. There is not much to gain in commonality if the platforms have diverged.

It's the opposite. The platforms (OCPL and OCDE) diverged many years before OKAPI has been created. When I was creating OKAPI, I needed to work with both OCPL and OCDE teams to understand these differences, and implement and test OKAPI so that it works in all OC instances. Both platforms are still diverging, and OKAPI implements a subset of the set of functionalities which are shared between both OCPL and OCDE. Some methods have been added by others developers since I stopped actively working on the project, but not many.

As said above I plan to address this state of affairs with the leadership circle at OCDE and see what course of action they suggest.

That makes sense to me. I'd still rather advise against forking though (confusion for external devs, potential problems with versioning and updating, etc.). Investing more time into making OKAPI extendible still feels to me to be a much better option for the user.

Greetings from snowy white Germany. Did you get some snow too?

Yeah, we had surprisingly a lot of snow in Zurich.

[wrygiel]

There's also one more solution, which might be on the table, if OCPL and OCDE devs agree - you could perhaps just be added to OKAPI developers, and your code would be submitted without any review.

IMO this might be the best option, but it would require you to invest some time into setting up your own OCPL dev environment (I'm insisting on that, because during your code review, I repeatedly noticed SQL queries which look like they would not work). I just saw an email from OCPL with this link, which might help? https://github.com/opencaching/deployment

[hxdimpf]

Pasting my response to your last email here too, for more context (might help with the discussion with OCPL and OCDE):

You are not the one who makes releases

When I was last working on the project, OCPL releases were automated, OCDE needed some work on OCDE side.

Yes, I talked to the devs there and there is a php composer action setup to pull okapi into the right place.

You are not the one who can afford the time to thoroughly review PRs (the time you spent is very very much appreciated and was of great help to me, thx much again!)

Yes, that's correct. I can still approve small, simple CLs, if you are fine with waiting 1-2 weeks.

Time is not an issue. Of course I can and I will wait. As mentioned above I had a discussion with OCDE dev and we concluded that we'd wait 4 weeks for an answer from the original OKAPI dev team.

It has already changed in the past. We had 2 other regular maintainers during the last couple of years, but they also left their post. That's why I say it might be temporary, as another maintainer might show up.

I figured out who they are and adressed them both via @.... in this issue. Let's see what they say.

It's the opposite. The platforms (OCPL and OCDE) diverged many years before OKAPI has been created. When I was creating OKAPI, I needed to work with both OCPL and OCDE teams to understand these differences, and implement and test OKAPI so that it works in all OC instances. Both platforms are still diverging, and OKAPI implements a subset of the set of functionalities which are shared between both OCPL and OCDE. Some methods have been added by others developers since I stopped actively working on the project, but not many.

Thanks for filling me in on the history.

As said above I plan to address this state of affairs with the leadership circle at OCDE and see what course of action they suggest.

In the meantime I did this, they have also started to look at the PRs. We agreed that we don't see forking as a good solution and that we'd be waiting for 4 weeks to see if we can continue keeping it common for all of us.

That makes sense to me. I'd still rather advise against forking though (confusion for external devs, potential problems with versioning and updating, etc.). Investing more time into making OKAPI extendible still feels to me to be a much better option for the user.

Yes!

[hxdimpf]

There's also one more solution, which might be on the table, if OCPL and OCDE devs agree - you could perhaps just be added to OKAPI developers, and your code would be submitted without any review.

IMO this might be the best option, but it would require you to invest some time into setting up your own OCPL dev environment (I'm insisting on that, because during your code review, I repeatedly noticed SQL queries which look like they would not work). I just saw an email from OCPL with this link, which might help? https://github.com/opencaching/deployment

This is indeed the best option and I am sure OCDE devs would agree as I in fact have joined the team by now anyway. I have actually tried to get the OCPL dev env going -- based on the virtual machine image that I found here on the repo, however, I couldn't get it working. I have a dev env running for OCDE though and that is where I tested the PRs.

I can see you have reviewed or re-reviewed one of the PRs. It was actually the first one I wrote and so it was the one where I had the least of experience with OKAPI (and the database too). I will fix the issues you mentioned there ASAP. Thx for taking the time.

[wrygiel]

I figured out who they are and adressed them both via @.... in this issue. Let's see what they say.

The ones you added (@kojoty and @deg-pl) are OCPL admins, which care for OKAPI in context such as PHP upgrades. In context of historic active development, I meant @teiling88 and @following5.

I will fix the issues you mentioned there ASAP

My point was - you need to be able to test them on OCPL. (It's not possible to catch all such bugs just by looking at the code.)

[hxdimpf]

I figured out who they are and adressed them both via @.... in this issue. Let's see what they say.

The ones you added (@kojoty and @deg-pl) are OCPL admins, which care for OKAPI in context such as PHP upgrades. In context of historic active development, I meant @teiling88 and @following5.

@teiling88 is in the loop

I will fix the issues you mentioned there ASAP

It is fixed by now.

My point was - you need to be able to test them on OCPL. (It's not possible to catch all such bugs just by looking at the code.)

Understood. And I agree wrt testing as very important. However, as stated, I don't have an OCPL dev env and setting one up for OCDE took me weeks even with hands on support from the OCDE devs. So what I'm saying is: It is virtually impossible for me to somehow generate a valid OCPL dev env on my own. How could I, for instance, get a snapshot of the database? ... to name one obvious point.

Let me ask this: Do you still have an OCDE dev env? Could you still test the OCDE path? And even more important: Do you still have an OCPL dev env and can you still test? If the latter of these two questions is yes, would there be a possibility that I could just use a clone of yours?

[wrygiel]

I don't. An snapshot of the database can be extracted from the VM image here. You could try using okapi/devel/dbstruct?compare_to= to migrate it to a current version.