socketio_listener:start/1 about socket.io-erlang HOT 14 CLOSED

I have these lines here (bit dirty I guess):

Pid = try
        socketio_listener:server(socketio_listener_sup)
    catch
        _:_ ->
            {ok, P} = socketio_listener:start([{http_port, 7878},
                                             {default_http_handler, ?MODULE}]),
            P
    end

from socket.io-erlang.

Looks like that'll work for now, I'll give it a try. Thanks!

-Greg

from socket.io-erlang.

@jannschu Unless I'm misunderstanding something, this rather sounds like the kind of code you should put in an application's start function so it is only executed once. Not the kind of thing you should dynamically call and match on each time.

from socket.io-erlang.

Assuming that opening a socketio listener is the only thing my OTP app does,
sure. Unforutenately, its not. Honestly, don't be lazy and crash when its
already started.

On Jun 11, 2011 9:33 AM, "ferd" <
[email protected]>
wrote:

Unless I'm misunder> Unless I'm misunderstanding something, this rather
sounds like the kind of code you should put in an application's start
function so it is only executed once. Not the kind of thing you should
dynamically call and match on each time.

Reply to this email directly or view it on GitHub:
#44 (comment)

from socket.io-erlang.

Assuming that opening a socketio listener is the only thing my OTP app does, sure. Unforutenately, its not.

Out of curiosity, I'm wondering about this right here. I get that an application can do more than one thing, but this part right there is almost part of something that could be considered initialisation and therefore only needs to happen once.

In fact, this could be something that would prompt us to move it to socketio's own starting functions, although I'd need to discuss that with the other contributors.

Don't be lazy and crash when it's already started

Although crashing is a valid option, it certainly is not OTP-like, given most named behaviours will indeed return you {error, {already_started, Pid}} in case of failure.

Because of this, I just made the correction in 8578f0f, which rather than returning the error tuple you requested instead always returns you the Pid you need no matter what. I don't think returning the Pid of the already started child made sense considering that was not what you were getting in the first place, but a listener instead.

Also be advised that calling me lazy did not push me in any way into making this decision. I respond much better when treated with respect when I am giving my time on a project that you can use for free, than when you try to insult me into committing stuff.

from socket.io-erlang.

Indeed, I DO only want to do it once. That's the whole points. Unfortunately, my restarting process that attaches to the listener currently has no way to cleanly (IMO that means without catching errors) do so without a lot of stuff that shouldn't need to be done.

I wasn't meaning to call you personally lazy, I was referring to the fact that not following OTP "standards" is lazy, the code itself is being lazy - it assumes to work and crashes if it doesn't - and there is no clean alternative approach. (One that doesn't couple my root app and sup to anything but their own children) This can be beneficial in cases and Erlang is the place for that, of course, but in an OTP application, it should return the already_started tuple like most other OTP compliant named apps so that the situation can be handled in the OTP manner rather than me getting an email at 4am to reboot my Erlang applications. My apologies for the perceived personal attack. You guys do great work, and I am appreciative of it. That very fact that I'm willing to use your code in my own projects should be considered an honor!

I wouldn't need to insult you to get you write two lines of code, dude. Chill out. I'd fork your code and do it myself (or write my own) before I'd insult you; me not doing that and bowing to the majesty of you guy's Erlang skills (and ultimately wanting a more solid product for F/OSS) is what I'm doing here. Sorry for the bad wording.

from socket.io-erlang.

Understood :) I'm a bit exhausted after this week and expecting the next one, so my temper is not as good as usual ;)
Let me know if the fix I've made (I've ammended it after I realized returning the tuple made no sense) works for you although you don't get the {error, {already_started, Pid}} value.

from socket.io-erlang.

Same situation for me here.

from socket.io-erlang.

for the temper or the fact it works/doesn't work?

from socket.io-erlang.

The comment was supposed to be an answer to your Out of curiosity question and situation should describe the OTP standards explanation from thrashaholic. So I just wanted to highlight the fact that the need for such functionality concerns at least two people :)

from socket.io-erlang.

Ah alright alright. Let me know if the fix I've made solves your issues. I've quickly tested it in my own apps and it seemed to work, although I didn't have the explicit need of matching on these things in the first place.

from socket.io-erlang.

Thank you ferd, your commits work great for me; as long as I can call something and get the Pid of the server without the kernel taking a dump on me, I'm happy.

I again apologise for any hostility on my part - it was certainly not my intention, I wrote that response in haste after sitting at a bar for four hours - I should have worded it better. Cheers mate, and again thank you for all your hard work - it has shaved months off of my time to market. :)

from socket.io-erlang.

Ah, this issue can remain closed then. Thanks for bringing this issue up, helping making socket.io-erlang better in the long run. No harsh feelings on my side either and I also apologise there. Let's consider it over on all aspects (as long as jannschu agrees this solves the issue) :)

from socket.io-erlang.

Just tested the commit. Works nicely, thanks!

from socket.io-erlang.