Python-based alternative server?

[connorgr]

What are your thoughts on including an alternate server implemented in Python? Experimentr's design keeps things pretty minimal on the server-side, and adding Python as an alternative could add more flexibility for how Experimentr could be deployed (e.g., better tie-in support for folks who use scikit-learn).

[codementum]

I'm all for it!

The one thing I'd add is that there should be a "server side" repo and a "client side" repo to avoid cluttering the repo.

I'm also thinking the modules should become their own repos at some point where you can "npm-install" them.

[connorgr]

Awesome. Do you have any ideas what the best organizational structure on
GitHub would be (e.g., fork or brand new repo)? My GitHub-Fu is not strong.
I have a working Python/Tornado stack example that I could push right now.

On Mon, May 2, 2016 at 2:44 PM Lane Harrison notifications@github.com
wrote:

I'm all for it!

The one thing I'd add is that there should be a "server side" repo and a
"client side" repo to avoid cluttering the repo.

I'm also thinking the modules should become their own repos at some point
where you can "npm-install" them.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#67 (comment)

[codementum]

I think for this something brand-new is fine. Maybe experimentr-python

Eventually we should have an "experimentr" org or move it to the lab org (wpivis)

[connorgr]

Cool. I'll set up a new repo asap :)

On Mon, May 2, 2016 at 3:22 PM Lane Harrison notifications@github.com
wrote:

I think for this something brand-new is fine. Maybe experimentr-python

Eventually we should have an "experimentr" org or move it to the lab org
(wpivis)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#67 (comment)

[connorgr]

ASAP might take a little longer than ASAP 😜. Ended up ballooning into a much larger scope, and I need to take some time to refine before pushing.

[codementum]

Neat!

Any cool new features / design reqs discovered along the way?

[connorgr]

There are some neat possibilities with using templates (even in Node),
which could help scalability on Turk if there are particularly
computational-intensive processes that could be pushed back to the server.
I haven't done anything with that though; slightly outside of what I'm
working on.

I have a couple convenience fixes on the client, and I'm working on some
more robust instrumentation code for optional interaction capture.

On Tue, May 17, 2016 at 11:32 AM Lane Harrison notifications@github.com
wrote:

Neat!

Any cool new features / design reqs discovered along the way?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#67 (comment)

[connorgr]

I think the largest change is a shift to Mongo from Redis, since PyMongo
has great support. I had a bit of trouble configuring redis, so went with
path of least resistance.

On Tue, May 17, 2016 at 11:39 AM Connor Gramazio connor@cs.brown.edu
wrote:

There are some neat possibilities with using templates (even in Node),
which could help scalability on Turk if there are particularly
computational-intensive processes that could be pushed back to the server.
I haven't done anything with that though; slightly outside of what I'm
working on.

I have a couple convenience fixes on the client, and I'm working on some
more robust instrumentation code for optional interaction capture.

On Tue, May 17, 2016 at 11:32 AM Lane Harrison notifications@github.com
wrote:

Neat!

Any cool new features / design reqs discovered along the way?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#67 (comment)