Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: Incorporate LcsApi library to the project #101

Open
milnet92 opened this issue Aug 21, 2024 · 3 comments
Open

Idea: Incorporate LcsApi library to the project #101

milnet92 opened this issue Aug 21, 2024 · 3 comments

Comments

@milnet92
Copy link
Contributor

Some months ago, I tried to standarize the API that is used in LCS based on the initial clients implemented in 2LCS. I ended up with this library. There are versions for .NET Framework and .NET Core 6 (not in sync), fully asynchronous, fully documented and with the following capabilities:

  • Almost every environment (from Tier1 to prod) operations are supported
  • Project settings
  • Project methodologies
  • Asset management (all operations)
  • Sizing
  • Diagnostics

Authentication through direct cookies and cookie capture (via Selenium) are supported.

The library comes with MIT license, so there is no problem with that :)

I think the project could potentially benefit from that implementation, being easier to maintain and expand, also allowing others to use it for automation purposes.

I can try to port it to this app myself, but I want to know if it is worth the efford. Thanks!

@FH-Inway
Copy link
Collaborator

Thanks for the suggestion, you are right, it would make totally sense to decouple the 2LCS client from the C# API wrapper. You did some impressive work there.
I would happily support you in this effort.

Regarding the "worth the effort" question: You are probably aware that Microsoft plans to discontinue LCS in the not so far future (a roadmap they shared a few months ago has December 2025 as decommission date, though with Microsoft, you never know). Assuming it will take at least a few months to make the suggested changes, the time window where this will see active use is limited.
Nevertheless, it is an interesting technical challenge and an opportunity to learn about API design and integrating an API in a client.

Again, happy to support this by reviewing and merging prs, testing and releasing new versions. However, to set expectations, the main part of the work would be on your side (and of course anyone else from the community that wants to join the effort). Let me know know your thoughts.

@TomekMelissa Tagging you in fyi and in case you want to share your thoughts on this.

@milnet92
Copy link
Contributor Author

Thanks for the heads up bout the decomission! I'm aware of the unified developer experiance but I see It as an opportunity to learn and contribute too.

How I plan to organize the transition is as follow:

  1. Create a new branch in this repo -> you'll be able to see and approve the changes OR I create a fork and add you as a reviewer
  2. Add my repo as a submodule while the API is not released as a package. In that way, I'll be able to modify the API and reflect the changes here.
  3. Refactor 👯

Let me know your thoughts, thank you.

@FH-Inway
Copy link
Collaborator

For point 1, I would prefer you create a pull request from your fork.

For point 2, using a submodule is a good idea while both sides are expected to change. For the final merge to master, it should use a package reference.

Have fun with the refactor 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants