The future of Simple.Odata.Client

[NetTecture]

Currently we have no new versions for a long time and pull requests are piling up forever. It is on a level where I would assume a lot of people do not even submit issues anymore, or put in any work to actually fix issues. Which means this library is falling behind - slowly, but faster.

I am working on a new odata client that is supposed to sit on top of simple odata client (removing the "totally untped" approach and generate client classes and libraries so I am able to combine ease of use together with the ability to get compile time errors in case the api surface changes) and I am i.e. considering not using simple.odata.client because of lack of updates.

It is quite clear that @object has moved on to greener pastures - most likely because his work has taken him away from odata so this is not an element he is actually using.

Could we please open a discussion about the future of this? Anyone has a contact of Vagif? Does it make sense to officially fork this off, rename it and put it under new maangement? Or would Vagif be ok to appoint a number of maintainers so that we could start updating references and merging in pull requests? I understand his terrific focus on quality - but at the same time, I start seeing this falling behind with no releases and this is not exactly helping with quality either. There is a lot of errors that are showing up with more advanced usage (thanks also to the odata team finally moving forward with some core functionality). I am not sure at this point which part of this would be worse. I would be willing, i.e., to donate some time towards some bugs - either from me personally, or from some people in my team. But with PR piling up for months - not going to happen. Had this dicussion with the EfCore team too. What sense is a PR if it does not go into a release within weeks? Wasted time. So, some maintainers that put that into more active PR's would be highly appreciated.

@object Can you please comment?

[object]

@NetTecture
Thomas, thank you for bringing this up. Yes, you are right, I have been busy (actually very busy) with other things that no longer use OData. Moreover, I even no longer use C#! I am using F# for my daily assignments. My last project that used OData was completed about 4 years ago, so it's been quite a challenge to keep up with news in OData world without ability to eat your own dog's food. So I will be happy to handle future maintenance of the library to other developers assuming they are willing to keep up with quality and principles of the library. I have been in contact with @phatcher and @watfordgnf, and of course @NetTecture has been using and contributing to the library for a long time.

So I am open to suggestions. The current state is not satisfactory and turns people down. There should be a continuous focus on both bug fixes and new feature development. I can also be contacted at vagif.abilov at gmail to discuss possible future of the library.

[NetTecture]

@object Well, I am willing at least temporarily just to step in and validate pull requests and stuff. For me Odata is a core of client projects AND our own infrastructure (which is more long term important to me). While it has some quite serious problems (odata - the standard) it is imho the best thing that is around. What we do need fast is being able to push up new releases and get maintenance going, then put in some sort of more community oriented way.

As direction, we definitely need to get the library up to standards. Not in the way of "make serious architecture changes" for now but "fix the bugs that we found and implement new features that odata has - like 'in' which finally was added". There is hardly any damage you can make to the codebase (tracked in git anyway) that is not offset by people actually SEEING something happening. The next step, imho, should be to get this somehow working in webassembly - blazor client side is a major step forward but it also is in dire need of odata ;)

This should IMHO get a council of multiple people that are maintaining it - it needs not to be revived, it needs to prosper. Damn to MS for not having a decent client - without decent client odata has no chance of larger scale use. I am maintaining a software for a major customer at the moment and they actively avoided odata in the past for other projects because of the complexity of dealing with it on both ends (client and server). This is the typical landscape these days. Now, the webapi odata team is getting their act together - 3.1 nightly are quite good and seem brutally faster than old libraries - but the client is a sour page and I find myself, i.e. more and more writing pure html unit tests instead of simple odata to test backend functionality because simple odata does not work in certain scenarios tue to bugs or limitations.

[object]

@NetTecture That's very good. I hope we will have feedback from others, then we can decide how we proceed.

[watfordgnf]

This library is a very important part of our products, and I'm on the hook for keeping this client library viable for our work. I'm available to review PR's and help shepherd the product going forward. However, because of the industry I work in we do not take updates frequently (our product is on an air-gapped network).

[aside: we're still on 5.6.1--and 4.3.0 before that--and are evaluating the jump to 5.10.X in our next release]

[object]

Thank you @watfordgnf, I have sent invitations to Simple.OData.Client organization to both you and @NetTecture, first as members, but we can promote you to owners.

[NetTecture]

Already seen it. I think the "most" important thing is getting the flow going, which will include whatever exists as build infrastructure (build servers, publishing). Is there anything? If not, it may be an idea to set up a (separate) microsoft azure devops organization for this - they integrate with github and can be used to host the build and deployment. Not saying we leave github - contrary. Azure would have all tracking disabled, basically just use the pipelines to make builds and upload upload them. I propose SHOULD come with a MINOR change on how branch naming conventions to allow gitversion to determine automatic version numbering ;) The goal basically being able to publish autoamtically to nuget. And make a new release based on merging in as many of the pull requests as we can. And then we should somehow make a rn through the open issues and prioritize them.

@object Can you make a wiki page on how to run the unit tests? Or is that absolutely trivial not requiring any setup?

[object]

@NetTecture It is trivial to run existing tests, they should just run. Extending tests may require taking taking care of HTTP response from the server and storing it in a repo, then using the stored file as for response validation. Library's unit tests are implemented in such away - they mock HTTP traffic.
And integration tests test against Microsoft's publicly available OData services, so they are also no brainers.

[NetTecture]

@object Interesting. Any automatic build setup so far or do you make deployments manually?

[object]

I should probably make a wiki page explaining how to do this. Currently it includes following steps:

1. Update version number
2. Build a solution
3. Run nugetpack.cmd to create NuGet packages
4. Run nugetpush.cmd to push packages to NuGet.

[SiberaIndustries]

Oh that's surprising somehow but it's also good to know that you are ready to appoint some successors. @watfordgnf is a very strict reviewer which means this is good and helps a lot. :-)

It is important for me to know whether this repository will be active in the future or not, because I have so many ideas for the future. For example, I am working on a temporary Manager-Library that wraps this library and extends it with features like API versioning, authentication or performance topics. It would be nice to see these features in this repo someday.

[object]

@SiberaIndustries No doubt that the project will be active in the future. With almost a million of downloads of its packages there is no way we can stop it :-) This is why we are trying to organize it better so it won't suffer from a bottleneck of a single individual.

[nsarris]

We are integrating with microsoft Dynamics365/CDS extensively and a lack of a propert microsoft client made using Simple a no brainer. We have taken the same path as @NetTecture and built a client on top, with a class generator etc.

I've commited a few PRs recently and I'd be happy to help out with a few more on some features that we'd love to have like deep inserts, nested selects etc.

[phatcher]

@NetTecture I don't mind setting up a Azure DevOps pipeline, we just need to come up with a sensible branching/versioning strategy so that we can publish betas etc,

For example, I didn't push my subtype changes for a long while as although they worked for me, I wasn't sure if they broke something else out in the wild.

[p3root]

What about GitHub Sponsor? I guess a lot of people use this library in a commercial way. I also use it in a commercial environment.

I want to ask every customer of me to pay 1€ per hour more, so that I can sponsor this money on open-source projects like yours.