[erlang-questions] Is using gen_server behaviour appropriate for his usecase?
Vineet Naik
naikvin@REDACTED
Fri Nov 30 17:44:26 CET 2012
@Roman
Thanks for the detailed explanation, those examples were really helpful
@Jachym
Thanks for replying. I am only half way through "Learn you some Erlang" and
picking up patterns from whatever I learnt so far from there. At this
moment I don't mind frameworks making decisions for me. But I totally
understand your point..
@Garret
Thanks, I will give e2 a try.
On Fri, Nov 30, 2012 at 7:18 PM, Garrett Smith <g@REDACTED> wrote:
> Roman is spot on correct.
>
> There's a school of thought that says new developers should learn core
> Erlang and master it before tackling OTP. IMHO this is wrong. OTP *is*
> core Erlang at this point.[1]
>
> Just use OTP, right away. If the many moving parts of the standard OTP
> behaviors seems like a steep learning curve, take a look at e2:
>
> http://e2project.org
>
> e2 is a veneer on top of OTP that, at least in my opinion (I wrote it
> for this reason :) makes canonical development a lot easier. You might
> start by reading/following the tutorial:
>
> http://e2project.org/tutorial.html
>
> The tutorial has more to do with general application development in
> Erlang than it does in with the specifics of the e2 library.
>
> Garrett
>
> [1] There's a long history of Erlang that separates the core from OTP.
> I understand how books, tutorials, teaching philosophies, and common
> wisdom would treat OTP as an advanced topic. But as a relative
> newcomer to Erlang, not having any historical context, etc. I found
> this treatment unhelpful in my own learning. IMO "gen_server" (e2
> calls these "services" and "tasks" depending on the scenario) is a
> starting point, after one has learned the basics of the language
> itself.
>
> On Fri, Nov 30, 2012 at 2:36 AM, Roman Gafiyatullin
> <r.gafiyatullin@REDACTED> wrote:
>> Hi,
>>
>> In most of the cases one shall not use "simple loop functions": raw
process
>> cannot participate properly in the supervision tree.
>>
>> If you need some new tricky specific model of behaving - better
implement it
>> over gen_server.
>> For instance supervisor is a gen_server :)
>>
>> If you need something more low level - use 'gen' module (see how gen_fsm
is
>> implemented).
>>
>> --
>> Regards
>> RG ( +375 33 602 5080, UTC+3 )
>>
>> On Friday, November 30, 2012 at 11:25 am, Vineet Naik wrote:
>>
>> Hello,
>>
>> I am an Erlang newbie and trying to write a simple chat bot as an
>> XMPP external component. I am using exmpp library and following
>> along these tutorials[1]
>>
>> So far I have one module `bot_server` that uses the gen_server
>> interface. Inside it's `handle_info` callback, incoming messages
>> from various client will be received. To handle and reply to the
>> these messages, I am thinking of spawning a "bot" process per
>> client. It will stay alive as long as the client is available
>> ie. when the client sends "unavailable" presence, it will die. I
>> also need to keep a list of all the alive bot processes in the
>> bot_server's state.
>>
>> My question is, would it be appropriate to implement the bot as a
>> gen_server too considering that it needs to handle two calls, one
>> for handling incoming message (asynchronous) and second for
>> killing itself (synchronous)?
>>
>> In general, when should one use gen_server and when should
>> one write a simple loop function?
>>
>> [1] exmpp tutorials:
>>
http://blog.process-one.net/scalable_xmpp_bots_with_erlang_and_exmpp_part_i/
>>
>> Thanks,
>> Vineet
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
--
Vineet Naik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121130/4a70840b/attachment.htm>
More information about the erlang-questions
mailing list