Skip to content

Conversation

mykola-mokhnach
Copy link
Contributor

Change list

I am still not quite sure what the purpose of such feature, but people have been asking for it.
The main issue is that Selenium API does not have a concept of session state, so we cannot reliably share it across multiple client instances. But we still can send commands, which is probably enough for debugging and other weird purposes.

The concept is simple, - all drivers got an additional public constructor, which accepts the remote session url (e.g. server url + "/session/id" prefix) and platform/automation name where necessary. The created "generic" driver only knows about the actual session id. Otherwise it is always assumed it is a valid Appium session using the W3C protocol.

Types of changes

  • No changes in production code.
  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Copy link
Member

@KazuCocoa KazuCocoa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems reasonable to me to set platfornName and automationName as no definition in w3c to get current session info.

I remember that I also got a couple of questions about this attach to an existing session long before. the main usage was for debugging to attach to a running automation session like current appium inspector's attach to an existing session in another language

@mykola-mokhnach mykola-mokhnach merged commit f575ee4 into appium:master Dec 5, 2022
@mykola-mokhnach mykola-mokhnach deleted the connect branch December 5, 2022 07:06
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

Successfully merging this pull request may close these issues.

4 participants