Feature: TCP server to listen for thread urls to save

[MaddoScientisto]

I've always wished I could run the program on a server and then remotely send to it threads to save, like from a PC application or from a smartphone app.

I've been recently getting into sockets programming so I think I could reliably set up a TCP server that runs and listens for urls to add to the watch list, then any client app that can send TCP requests will just have to send a properly formatted string with the data and the application will act accordingly.

I'm going to start implementing it soon for personal use, do you think I should commit it for the public once I'm done with it?

[jwshields]

I like this idea, but I also believe it would be outside of the scope for this project (not to say I'm a PM on it or anything...) I think it would be nice to have a remote way to add URLs to watch, but that being said, you'd need to add in the code on the "server" side, be able to account for NAT traversal (or figure something out), you'd need a client to be able to communicate with it - because I'm sure not all people would be cool with writing directly to a TCP socket ;)

And in addition, why not multi-platform this, a CLI-Linux executable would be nice, but like I said, an idea as you've brought up, it feels way outside of the scope of this application.

[MaddoScientisto]

I guess it could be done with a small webserver instead, in that case you just got to show a Web form with a textbox and then fire a Post or Get request with the url.

Also I too had the idea of making a CLI front-end, I was researching to see if it could hook into the already existing classes from the main form application and then use them just like the form does. If it can be done like this the it's just trivial to have the application run in the background. I've been recently writing a CLI application with mono so I think I could do that and once we have a web server we can serve the saved pages over the same interface.

What do you think? On Jun 18, 2014 12:58 PM, "jwshields" [email protected] wrote:

I like this idea, but I also believe it would be outside of the scope for this project (not to say I'm a PM on it or anything...) I think it would be nice to have a remote way to add URLs to watch, but that being said, you'd need to add in the code on the "server" side, be able to account for NAT traversal (or figure something out), you'd need a client to be able to communicate with it - because I'm sure not all people would be cool with writing directly to a TCP socket ;)

And in addition, why not multi-platform this, a CLI-Linux executable would be nice, but like I said, an idea as you've brought up, it feels way outside of the scope of this application.

— Reply to this email directly or view it on GitHub https://github.com/SuperGouge/ChanThreadWatch/issues/22#issuecomment-46421373 .

[SuperGouge]

As stated by jwshields this seems a lot outside of our scope. Having two versions of the program (client and server) would be an unnecessary bore IMHO. However on the idea of remote controlling, having a Web UI that could be accessed over HTTP is feasible and a lot more convenient for both users and developers.

[MaddoScientisto]

I will start working on it then. To begin after adding the webserver itself (I still haven't decided what to use) it will server a single page with a form for sending in urls, eventually I'll make it list every saved thread and it will be possible to browse them.

Then I don't know, maybe I'll add settings, authentication, etc

[SuperGouge]

Thanks a lot for your contribution to this project.