etpan-down and etpan-up

[yorkie]

Hi, @dinhviethoa. I have a thought wanna share with u about this node module. that's we need split this module to 2 complete library: etpan-down and etpan-up, their relationship just like rvagg/node-levelup and rvagg/node-leveldown.

Then:

• etpan-down just dose parsing, it is totally a js binding with partial of libetpan.
• etpan-up just does API stuffs, that uses etpan-down to construct a bundle of APIs more like javascript/nodejs, and do more about networks.

Actually we need to do this is:

1. remove network related API in libetpan.node, and expose only parsing API to usage, and rename this module to etpan-down.
2. create a new repo named etpan-up, and construct an API more like andris9/inbox.

I prefer like to do the above jobs and let them works fine in my spare time, but I need some thoughts of you, the author of libetpan.

/cc @dinhviethoa :)

[dinhvh]

If both are meant to live together, I'd prefer them to be in the same node module / repo. Why can't the current API be though as the low-level API for libetpan. Then, you could high a high-level API similar to inbox on top of it.

Does it sound good?

Is there any specific reason why you would like to remove the network calls from here?

[yorkie]

Yes, IMO this library should like mailparser that only does parsing stuffs, but in a fast way than mailparser.

Plus, there are the following 2 reasons that support my opinion:

• The libetpan.node without networking calls would be more free for building etpan-up module
• The current binding API of libetpan.node has ever not contained networking part.

Do you have any more thoughts on this?

[dinhvh]

Is there a reason to keep them in two separate modules? I support the idea of separating the parsing layer and the high-level layer but I'm not sure if that's worth to have two separate modules for it. They could be in separated folders instead.

[yorkie]

Only 1 module seems good to me, but exposing the parsing APIs is necessary for the new libetpan.node. But if the future module, etpan-up is a pure javascript module, that would be better for open source and easy compatible implementation for node(for example this module could not be compiled at v0.11.x).

[dinhvh]

Ok. Let's break it in two parts. How about libetpan.node for the low-level API (JS bindings to C) and mailcore.node for the high-level API? Could you take a look at mailcore API https://github.com/mailcore/mailcore2 (src/async, it's some C++ API) to help you define some high-level APIs?

[yorkie]

Amazing, a wise name for mailcore.node but node-mailcore seems like a pure javascript's name? Ok, I would build new API based on mailcore2's :P

[dinhvh]

Sounds great! FYI, I initially though that we could build node-mailcore on top of mailcore but after a some investigation, I found out that how mailcore was built was not the best way forward. So, building on top of libetpan.node and try to match mailcore2 API would be the best option.

node-mailcore sounds good to me.

[yorkie]

Plus, we might use rvagg/nan to resolve the compatible problem for node versions on libetpan.node.

[yorkie]

Okay, and I would start this works from libetpan.node. cheers :cherries:

[dinhvh]

Awesome!