Compilation issues for fasthash dependency

[samfrench]

This looks to be a great project for supporting Optimizely in Rust and has most of the features needed for experimentation.

I ran into issues compiling this locally on a Mac for "fasthash". I was wondering why this was used or how much faster it is than other options. I modified this to use "murmur3" and got it working.

I was having issues such as flier/rust-fasthash#28 and see there are a lot of other open issues for similar compilation issues across other devices.

I am wondering if it is worth submitting a PR to use a different hashing library or if there were specific reasons fasthash was chosen.

[MarkBiesheuvel]

Glad to hear that you're interested in using Optimizely in Rust.

I looked back through earlier commits to see if I could find the reason for using fasthash over murmur3, but could not find it.
This is the earliest implementation of the bucketing functionality and I was using fasthash here already: https://github.com/MarkBiesheuvel/optimizely-rust-sdk/blob/2654644d1f795532a068e86644e8c32fa8040f6a/tests/playground.rs

A pull request is definitely welcome.

Currently, the SDK is a just pet project of mine, so the SDK is unofficial. However, if there is interest from our customers, we will consider making the SDK official. Are there any particular use cases you are looking to support within BBC?

[samfrench]

I created a PR here: #18.

Happy if you want to suggest improvements as relatively new to the language.

At the moment I am just trying out a few ideas more as a proof of concept. I am surprised there isn't an official SDK to use but one will probably appear over time.

I have a few thoughts about this SDK as the majority of features are there, such as the decision making. Will any caching be coming for the client and/or datafile? I see updating the datafile in the background is in the todo list, but this is something that would be useful. Maybe even configurable to allow it to be updated as frequently as needed, otherwise defaulting to 60 or 300s to update every so often.

At the moment I have cached the client as I saw it was making a request for the datafile on every incoming request when a decision was made. Ideally this caching would be in this Optimizely library so any new client would share an existing one. To achieve this with "once_cell" I had to add Sync + Send to the EventDispatcher. Maybe I missed something and there is an option to make fewer requests when parsing the same datafile for various users.

Happy to discuss further somewhere or see what will be coming as part of this SDK.

[MarkBiesheuvel]

Solved by #18

[MarkBiesheuvel]

@samfrench Regarding your question, ideally you would indeed create the SDK client once and re-use it for multiple requests.
Similar to the scripts in /examples folder.

Are you using a particular web framework where it is not possible to persist variables across multiple requests? (I haven't used web frameworks in Rust before, so excuse my inexperience).

Feel free to create another issue to continue this discussion.