Update Main Wiki Page

[kb1lqc]

The main wiki page for this project is outdated and should be cleaned up to reflect the current understanding of this project.

This will reflect the project prior to actual implementation of a faradayio program. However, I have a much better understanding of the direction of this project than I did when that page was originally created. Updating for the Initial Test Suite milestone will help future developments.

• [x] Link to known wiki pages so far (Table of Contents)
• [x] Provide some context of the project in relation to the wiki

[kb1lqc]

I added the initial simple Wiki updates: https://github.com/FaradayRF/faradayio/wiki

• Cleaned up main page
• Added custom sidebar with links to relevant pages
• Added custom footer

[kb1lqc]

OK I have a conundrum @kb1lqd @hdkmike @reillyeon @el-iso @lqdev ... I realize that my initial thought of this faradayio module being both a python module and a command line program may not be the best path forward.

Both Module and Command Line Program

• The faradayio module is pretty specific and while hardware agnostic it's not like it's going to be used by millions of people. Its main goal is to provide TUN/TAP interfacing to a serial port with SLIP protocol messages.
• This keeps the installation easy. Just install the faradayio package and you have both the module and the end user program that uses it to provide a network adapter for Faraday radios.

Just a module

• Keep the code simple and create some other project such as faraday-adapter that uses faradayio to provide command line program(s).
• Potentially a lot more work creating a repository for a simple program

Your Thoughts?

What do you all think? I'd like some input about this since I want to keep this code as high quality as possible (YAY UNIT TESTING!!!) but also sane.

[lqdev]

I think the latter (just a module) might be the best approach. This allows you to focus on the core functionality of faradayio without having to worry about coupling it to any particular UI/UX use case. As you mentioned, "Its main goal is to provide TUN/TAP interfacing to a serial port with SLIP protocol messages.".

I think we can draw a parallel to the python requests module. In my opinion one of the main goals of requests is to simplify HTTP functionality. How individuals use it (console app, web app) is a detail that I assume the authors do not concern themselves with and leave it to developers using it to decide that. Of course, you can build POCs to demo how individuals might integrate it into their own apps, but at the end the main focus is the core functionality of the module as opposed to the UI.

[kb1lqc]

Yeah good rationalization there.

---- On Tue, 30 Jan 2018 10:20:03 -0800 notifications@github.com wrote ----

I think the latter (just a module) might be the best approach. This allows you to focus on the core functionality of faradayio without having to worry about coupling it to any particular UI/UX use case. As you mentioned, "Its main goal is to provide TUN/TAP interfacing to a serial port with SLIP protocol messages.".

I think we can draw a parallel to the python requests module. In my opinion one of the main goals of requests is to simplify HTTP functionality. How individuals use it (console app, web app) is a detail that I assume the authors do not concern themselves with and leave it to developers using it to decide that. Of course, you can build POCs to demo how individuals might integrate it into their own apps, but at the end the main focus is the core functionality of the module as opposed to the UI.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

[hdkmike]

Yeah, I agree with @lqdev. Separate them. Create a faradayio-cli or faradayio-ui that depends on faradayio and imports it. It’d serve as an integration example and limit scope to the repo.

[kb1lqc]

Thanks @lqdev and @hdkmike. I'm going to close this ticket as I will keel faradayio its own module and build a separate project for the user interface.