couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Somov <trophyb...@googlemail.com>
Subject Re: community of CouchDB developers in the Netherlands
Date Fri, 16 Sep 2011 07:57:16 GMT
Thank you Randall.
Even though I have read a lot about the gen_server  I still have a lot of
difficulties to understand both the big picture and the small details of the
implementation.
That is why I was hoping to find someone who can guide me in the very
beginning.
In person it can be so much easier...
Apparently, here in the Netherlands Erlang is not that popular. (which is
also an indication that it should be impossible to find a job with Erlang)

Cheers,
Andrey

On Thu, Sep 15, 2011 at 6:45 PM, Randall Leeds <randall.leeds@gmail.com>wrote:

> On Thu, Sep 15, 2011 at 05:38, Andrey Somov <trophybase@googlemail.com
> >wrote:
>
> > Thank you very much for your time and efforts.
> > It helped me to understand something but for each explanation I got 10
> new
> > questions :)
> >
> > Just the first one.
> >
> > *>> open_async(Server, From, DbName, Filepath, Options) ->
> > >>    Parent = self(),
> > >>
> > >First, store the current process ID so it can be accessed later on, from
> a
> > >closure running in another process.*
> >
> > There is only one couch_server process. It is created like this:
> > gen_server:start_link({local, couch_server}, couch_server, [], []).
> >
> > As far as I understand it means that there is no need to remember the
> > process ID (Parent), and instead of
> > gen_server:call(
> >                Parent, {open_result, DbName, Res, Options}, infinity
> >            ),
> >
> > we can use
> >
> > gen_server:call(
> >                couch_server, {open_result, DbName, Res, Options},
> infinity
> >            ),
> >
> > I have many more but to avoid misunderstanding I would propose to stop
> > here.
> > I will try to dig further myself.
> > When I have specific questions I will try to approach this list.
> >
> > Thank you !
> >
>
> Andrey,
>
> This is exactly right. Although, the 'safer' thing to do which makes
> refactoring easy is to use the special constant ?MODULE to refer to the
> name
> of the current module.
> More than one way to get things done :)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message