stevepryde / xenon Goto Github PK

Hey @stevepryde,
It seems to me like a good library/crate/binary.

It is possible to pass any capabilities/settings to the webdrivers or at least have a custom default settings such as --headless arg for geckodrver or chromedriver?

I've played with the code in order to have it done but haven't succeeded :(

I was experimenting with the data here.

Thanks

After benchmarking some tests against selenium I discovered that the logging is hurting performance quite a lot. Seeing typical performance about 30% slower than selenium.

After commenting out the logging of every request performance jumped up to slightly faster than selenium (roughly 7%).

I suspect part of the problem is that logging is synchronous and Xenon is async. However I couldn't find any async logging libraries. What I found instead is the suggestion to do all logging from a single thread and use a channel to send logs to that thread. I think that would be worth exploring. It should be pretty easy to do.

Also perhaps logging should be turned off by default unless turned on via capabilities (or environment variable / command-line option)?

Hi!
Thank you for your great crates!!!

cargo install xenon-webdriver

 Compiling xenon-webdriver v0.4.1
error[E0603]: module `export` is private
   --> /home/f/.cargo/registry/src/github.com-1ecc6299db9ec823/xenon-webdriver-0.4.1/src/nodes.rs:6:12
    |
6   | use serde::export::Formatter;
    |            ^^^^^^ private module
    |
note: the module `export` is defined here
   --> /home/f/.cargo/registry/src/github.com-1ecc6299db9ec823/serde-1.0.137/src/lib.rs:274:5
    |
274 | use self::__private as export;

stable-x86_64-unknown-linux-gnu unchanged - rustc 1.61.0 (fe5b13d68 2022-05-18)

Sometimes we need to configure webdriver binary (geckodriver/chromedriver etc.). through arguments.

For example path to executable (firefox/chrome) since it may have not standard location.

As I see currently we pass only port which handled internally.

We could add a list of specific options or a custom list which may be benefitial

I'll tackle it later if you don't mind and if you consider that's suitable change.

Actually people could create a bash script or something like that and just put a path to it in a config instead of a real binary. It would solve the issue. But it would be necessary for them to deal with arguments which you set up which is not nice (maybe)

One feature that was always in the plan was to support running multiple nodes, possibly on different hosts, and be able to forward requests over the network.

The basic idea is pretty straightforward. Xenon itself, being a proxy, can act as a WebDriver server. Therefore, if we want to forward requests to another instance of Xenon, rather than chromedriver etc, this should "just work" if we wire up the Xenon nodes as if they were just another session. Further, we don't need to worry about managing the number of browsers per node because Xenon already does this. If Xenon can expose the list of browsers it has, then the upstream Xenon instance (i.e. the hub) can just match on those and if matched, try to create a session. If it fails, move on to the next match. If all fail, return NoMatchingBrowsers etc.

There are a couple of ways to do the configuration. One way is to put the node configuration in the hub config file. There are advantages to this approach, one being that it's easier to figure out where a request might go. Just follow the chain. However, there are downsides too, mostly around what happens if a node becomes unreachable.

The other way is to put the hub address in each node's configuration. This seems better, because in theory you could have multiple nodes all with the same configuration. However, the hub also needs to know the address of each node, so that it can forward requests there. It's probably possible to use the remote address of each node when they register with the hub, but i don't know how reliable this would be across all networks. To start with, I'm thinking it's probably ok just to have each node tell the hub its address and port explicitly. Also, if a node goes down, it can just register again when it starts back up.

There is also no difference between a hub and a node. I'm designing this so that any individual Xenon server could have its own local sessions and also remote sessions offered by other nodes. You could also nest the nodes several layers deep, however there are performance penalties (network latency for every stacked request) for doing this. It might also be possible to end up with a circular route which would cause issues. I'll tackle this and other related complexities once the basic design is working.

I've already started on this - check out the nodes branch if you want to follow along. Feel free to offer advice if you think the design could be improved or if there's a better approach. This is not currently functional but it's getting close.

I think it doesn't necessary to provide a path. By default xenon could assume that it's visible (driver could be located through $PATH)