[erlang-questions] Would like some feedback

Pierre Fenoll pierrefenoll@REDACTED
Wed Nov 25 09:41:12 CET 2015


On making prevkeys.erl (or should I say axolotl_prevkeys.erl) more readable:

Match your records in your function head instead of extracting their fields
one by one.

Create a session_data record that could be exported as an opaque type and
implement accessors.
Typically this would go in its own module.

Nice work


Cheers,
-- 
Pierre Fenoll


On 25 November 2015 at 00:55, Chandru <chandrashekhar.mullaparthi@REDACTED>
wrote:

> Hi Frans,
>
> Here are a few comments with the caveat that I haven't spent any time
> understanding the protocol. So the comments are more about implementation
> style...
>
> - Firstly, its quite impressive you've managed to write this in quite an
> idiomatic style for your hobby project, so well done!
> - You might want to consider naming all your modules with the 'axolotl_'
> prefix to minimise the possibility of module name clashes when others use
> your code
> - It would be a good idea to put all your DB access operations in a module
> such as axolotl_db.erl so that if you ever wanted to changed your database
> backend, the changes are limited to one module. It might not be that
> important for this particular application, but as rule of thumb it will
> serve you well.
> - You raise a good question about "... decide what goes into a new process
> or is done in the calling process...". I'll try and clarify this with an
> example. You have implemented identities:check_registration/2 as a
> gen_server:call, but the code which handles this message in the handle_call
> function is just reading from mnesia and returning a result. This need not
> be a gen_server:call, it can be written as follows.
>
> check(Registration_id, Dhi_pub) ->
>     case mnesia:dirty_read(identity, Dhi_pub) of
>         [#identity{registration_id = Registration_id}] ->
> true;
>         _ ->
> false
>     end.
>
> This is because there is no value in putting it through the gen_server. It
> still makes sense for the code to reside in this module as it logically
> belongs here.
>
> - Typically with Erlang applications, your mnesia initialisation code
> should be separate from your normal running code. It is okay to expect the
> user to run a one off installation function to create the required tables.
> Also, it is not a good idea to delete schema and recreate it because it
> becomes hard to use this as part of a node with other applications which
> have their own mnesia tables.
>
> - The code in prekeys.erl is a bit hard to read. You might want to move
> the code from each of the handle_call function clauses into separate
> functions which are invoked. This is probably partly due to my ignorance of
> the protocol, but the code could be made to look cleaner.
>
> - I couldn't see any test code in the modules, how are you testing this?
>
> I hope this is of some help.
>
> cheers,
> Chandru
>
>
>
> On 24 November 2015 at 18:18, Frans Schneider <schneider@REDACTED> wrote:
>
>> Dear list,
>>
>> I've been learning Erlang in my spare-time for some time now and would
>> love some feedback on a project I recently started. Since I have no
>> coworkers or other people to get feedback from, maybe somebody on this list
>> could have a quick look.
>> The things I find particular difficult is defining a proper API, to
>> decide what goes into a new process or is done in the calling process and
>> dealing with errors. I have no formal training as a programmer which may be
>> the reason I have trouble to get these things right.
>>
>> The project I took [1] was to implement the Axolotl ratcheting protocol
>> from Open Whisper Systems [2]. The protocol [3] itself didn't look very
>> difficult, but since there are no proper specs for the total system, I used
>> the libaxolotl-java implementation as a starting pont [4]. Reading the Java
>> code probably was the hardest part of the whole project.
>>
>> I think I covered most of the functionality of the libaxolotl-java
>> library. I haven't verified interoperability between my implementation and
>> libaxolotl-java since that would require me to start coding in Java which
>> is not something I am looking forward to.
>> Comparing my Erlang code with the original Java code, I needed far less
>> lines of code and, I think, the code is much easier to understand. Also,
>> building and deploying the code seems much simpler.
>>
>> So, any comments are most welcome.
>>
>> Thanks,
>>
>> Frans
>>
>> [1] https://github.com/schnef/axolotl
>> [2] https://www.whispersystems.org/
>> [3] https://github.com/trevp/axolotl/wiki
>> [4] https://github.com/WhisperSystems/libaxolotl-java
>> Nice implementation https://github.com/rxcomm/pyaxo
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151125/dc82422f/attachment.htm>


More information about the erlang-questions mailing list