Specify Port and Other Sinatra/Rack Arguments via Command-Line FReCon
rye opened this issue · comments
As it stands now, one cannot use -o 0.0.0.0 -p 1337 to open up the server on port 1337, as Sinatra, or its internals, at least, are not given the values. It seems that ARGV doesn't go through correctly or something.
Any ideas, @Sammidysam?
It would also be good to note that we should probably have a functional usage thing; frecon c and frecon s is not a very solid process selection thing.
We can pass arguments in via GetoptLong. Then, the first of any leftover arguments can be RegExp-matched to figure out if it's the server or the client.
We might also want to consider looking into having a dynamic usage page; we could create an Argument class, with a to_getoptlong instance method that would return the appropriate thing to pass to GetoptLong. We can enclose this Argument class in an ArgumentParser module which would include the ability to run the GetoptLong magic and return some Proc to be called, or just to start doing things.
Basically, we just need to beef up the executable.
In my recent Ruby application, I used OptionParser to parse arguments, and it worked incredibly nicely. I have much better memories using it than when I used GetoptLong in Python (I assume using that in Python and Ruby would be very similar). I would prefer using this in the event of improving the executable.
Thoughts?
Thanks for the link and the suggestion.
I do like OptionParser. Seems like a good idea, especially because it seems to have support for tab completion (though I have no knowledge of how well it works). I'm fairly confident in saying that any implementation of anything in Python isn't going to be the same as in Ruby, and GetoptLong's implementation in Ruby certainly works, but you do need to do a bit more boilerplating than you would with OptionParser.
Bottom Line: we can definitely use OptionParser instead.
Would you agree, however, that making the thing dynamic so that we can easily add support for more arguments would be nice? This would involve writing a similar thing to the Model class and inheritants' subdirectory, but with a new Argument class.
I mean, with how easy adding an argument with OptionParser is, I don't feel like a whole class is even necessary.
It would be nice to mirror the functionality of rackup so that we can easily define ports in the same way that we would if we were running an implementation with a config.ru file (like WeBCa).
It is certainly true that adding an argument within OptionParser is easy, but a counter point is that routing something in Sinatra is just as easy. That's what we'd be going for: the situation where we have a file that automatically goes through all descendants of a new Argument class and adds them dynamically to the OptionParser structure. With this, we can also then define the usage information within each class as a class variable.
It may not seem overly important, but if we want to add more fine-grained control, we may find that having one file with all of our arguments and all of the setup code within it might not be the best.
I can certainly work on some prototypes for you, if you'd like. [EDIT: This would definitely help me to familiarize myself with OptionParser.]
I am curious to see what it would look like, if it is not too burdensome.
-Sam
Sent using CloudMagic [https://cloudmagic.com/k/d/mailapp?ct=pa&cv=7.0.42&pv=5.1] On Sat, Aug 01, 2015 at 3:44 PM, Kristofer Rye < notifications@github.com [notifications@github.com] > wrote:
It would be nice to mirror the functionality of rackup so that we can easily define ports in the same way that we would if we were
running an implementation with a config.ru file (like WeBCa).
It is certainly true that adding an argument within OptionParser is easy, but a
counter point is that routing something in Sinatra is just as easy. That's what
we'd be going for: the situation where we have a file that automatically goes
through all descendants of a new Argument class and adds them dynamically to the OptionParser structure. With this, we
can also then define the usage information within each class as a class
variable.
It may not seem overly important, but if we want to add more fine-grained
control, we may find that having one file with all of our arguments and all of
the setup code within it might not be the best.
I can certainly work on some prototypes for you, if you'd like.
—
Reply to this email directly or view it on GitHub
[https://github.com//issues/55#issuecomment-126948455] .[https://github.com/notifications/beacon/AC7z1sH4GXs2lgs2-1cf2UIGfhOqIfw3ks5ojRkZgaJpZM4DzW0B.gif]