List all devices

[kalkov]

It will be nice to list all devices with :

RubySpark::Core.devices

I can try to implement that.

[efatsi]

Would be nice yes. Thoughts on starting up a RubySpark::Account class that's initialized with just the access token so you could call RubySpark::Account.devices instead?

I've added a Cloud class to my fork of the project, which implements this and more. While, I haven't submitted a pull request as all of the desired tests aren't written and I haven't updated the readme. I will push my what I've got to my fork and post here.

You can view my take on expanding RubySpark functionality on my fork (https://github.com/lhalff/ruby_spark), lacking documentation and complete test coverage. Feedback welcome, and let me know if it looks useful enough to be incorporated.

[efatsi]

@lhalff interesting approach, I like what you're doing here. Looks like it's more or less backwards compatible with the current version as well. Do you think it'd be worth it to break out the access_tokens and core related methods into a separate class? So the Cloud class just deals with the API calls? It might not be worth the trouble, just a thought.

I can look into helping out with the spec coverage later this week (although it looks like you covered most of it) if you think you'd be able to get the documentation up to date?

Thank you, I did aim to maintain backwards computability. I like the idea of breaking out Tokens into a separate class. Since, a Core require a Cloud, are you envisioning a method like RubySpark::Core.devices_in(Cloud)?

I'll work some more on the code and documentation today and tomorrow, help with the coverage would be great. I think deleting tokens in the cloud is currently broken, I was getting timeouts yesterday.

[efatsi]

RubySpark::Core.devices_in(Cloud) isn't really what I'm thinking. I'd like to keep the structure of classes in the Gem aligned with how these things exist in the real world. So I think it's fine that tokens and cores are methods in the same class, since those are things you're querying off of the top level Spark Cloud. But it might be nice to move the interactions with the API (the request and handle methods) into a separate class. So the Cloud class, and the Core class both rely on that to handle the API interactions.

Again, I think the current implementation is fine as is but I think that'd be a nice refactoring.

[nixpulvis]

The Cloud class is definitely the way to go here.

Thank you for the explanation @efatsi. I had thought about abstracting the request and handle methods to a separate class, but couldn't come up with an instance where a Core would make a request without a Cloud. But, yes, I agree that would be a nice refactoring.

I just pushed (e94c35e) a proposed implementation of @efatsi's suggestion to extract the token and api requests into separate classes. In looking forward to implementing support for SSE. Caveat: there very likely be bugs here, tests need to be built and documentation needs to be written if this looks like a good path forward for the library.