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

Hide server initializer from a base URL #1100

Closed
1 task done
defagos opened this issue Dec 12, 2024 · 1 comment · Fixed by #1102
Closed
1 task done

Hide server initializer from a base URL #1100

defagos opened this issue Dec 12, 2024 · 1 comment · Fixed by #1102
Assignees
Labels
enhancement New feature or request

Comments

@defagos
Copy link
Member

defagos commented Dec 12, 2024

Description

As a Pillarbox developer, I want SRG SSR content to be provided only by IL, thus avoiding bad practices within SRG SSR.

Hints

Read internal discussions here.

Acceptance criteria

  • There is no way to use a non-official server with CoreBusiness PlayerItems.

Tasks

  • Prevent server initializer from a base URL somehow.
@defagos defagos converted this from a draft issue Dec 12, 2024
@defagos defagos added the enhancement New feature or request label Dec 12, 2024
@defagos defagos moved this from 📋 Backlog to 🚧 In Progress in Pillarbox Dec 12, 2024
@defagos
Copy link
Member Author

defagos commented Dec 12, 2024

The existing public Server.init(baseUrl:queryItems:) promotes a way of using Core Business with services able to pose as the IL. This is what we want to avoid.

Still we want to be able to use this API in our demo during the IL to SAM transition. Some ideas and results:

  • Make the method internal and use Swift 6.0 new internal imports: We cannot compile for 6.0 yet.
  • Make the method internal and use @testable: This does not work in app targets.
  • Mark the method as deprecated: This litters our compilation logs with warnings we cannot silence.
  • Keep the method public but use an assertion to ensure it is only used in our demo, and replace the documentation with a warning. This is likely our best option.

@defagos defagos linked a pull request Dec 12, 2024 that will close this issue
4 tasks
@defagos defagos moved this from 🚧 In Progress to 🍿 Code Review in Pillarbox Dec 12, 2024
@github-project-automation github-project-automation bot moved this from 🍿 Code Review to ✅ Done in Pillarbox Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: ✅ Done
Development

Successfully merging a pull request may close this issue.

2 participants