Nan2

[sonnyp]

WIP; could use some help

[sonnyp]

is this correct?

[rvagg]

correct but you should use Nan::Set(target, Nan::New<String>("StringPrep").ToLocalChecked(), t->GetFunction()); now for max-compatibility

[austinkelleher]

+1 Need this very much. Looking to moving to Node 4.1.0.

[philidem]

👍

[erulabs]

👍 as well! Thank you for your efforts!

[lloydwatkin]

@rvagg is usually very helpful with nan stuff if we ask nicely... please? :)

[erulabs]

@sonnyp I've started another effort here: #74

[austinkelleher]

The Nan2 support that @erulabs has started is looking pretty good so far.

[rvagg]

can be removed from inside all NAN_*() methods

[lloydwatkin]

You rule @rvagg, thanks!

[sonnyp]

../node-stringprep.cc: In static member function ‘static void StringPrep::Initialize(v8::Handle<v8::Object>)’:

../node-stringprep.cc:24:50: error: ‘NanAssignPersistent’ was not declared in this scope

     NanAssignPersistent(stringprep_constructor, t);

[rvagg]

stringprep_constructor needs to be declared as a Nan::Persistent now (instead of just Persistent, i.e. v8::Persistent) and then you use stringprep_constructor.Reset(t) here

[sonnyp]

../node-stringprep.cc: In member function ‘v8::Local<v8::Value> StringPrep::prepare(v8::String::Value&)’:

../node-stringprep.cc:115:5: error: expected initializer before ‘size_t’

     size_t destLen = str.length() + 1;

[sonnyp]

@rvagg thanks a lot for the help

I ported @erulabs work from #74 and your comments here.

I added the last build errors as comments. Additionally if you could double check the PR that would be great.

[erulabs]

Hey @sonnyp looks like a missing semicolon on line #114

The remaining issue seems to be how we return the value (lines 228 & 279):

Local result = Nan::New(dest, destLen).ToLocalChecked();
info.GetReturnValue().Set(result);

This passes tests, but appears to break the unicode/ascii conversion. I tried a handful of ideas without much results. +1 to big big thanks to @rvagg 💃

[sonnyp]

@erulabs

../node-stringprep.cc: In function ‘Nan::NAN_METHOD_RETURN_TYPE ToUnicode(Nan::NAN_METHOD_ARGS_TYPE)’:

../node-stringprep.cc:228:11: error: missing template arguments before ‘result’

     Local result = Nan::New(dest, destLen).ToLocalChecked();

           ^

../node-stringprep.cc:228:11: error: expected ‘;’ before ‘result’

../node-stringprep.cc:230:31: error: ‘result’ was not declared in this scope

     info.GetReturnValue().Set(result);

https://github.com/node-xmpp/node-stringprep/pull/72/files#diff-4e17e0441c265ec99c496bc09f563bc2R228

[erulabs]

Yeah - it should be a Local for sure, which builds properly, but breaks the actual tests. I get the feeling that something here is breaking our unicode/ascii converstion

[erulabs]

I wonder if we can reach out to the original authors of node-stringprep.cc and see if they have some advice for us since it seems like we've hit a dead end :(
@pixelglow @dodo @lloydwatkin I hope this isn't bothersome - any pointers to help us convert to NAN2 without breaking the package would be hugely appreciated :) Thanks!

[lloydwatkin]

Actually @astro is the original creator AFAIK, I've just been keeping it ticking over. I'm afraid native module binding isn't something I'm familiar with.

[sonnyp]

As far as node-xmpp is concerned I don't think we should spend much time on node-stringprep. RFC 7622 deprecates the use of stringprep see https://github.com/node-xmpp/JID/issues/1

I have made a standalone and stringprep-free module for JID at https://github.com/node-xmpp/JID and plan to use it in node-xmpp-core see https://github.com/node-xmpp/node-xmpp-core/pull/76 . (Somehow all original tests passes without stringprep)

I understand it's not fully compliant but neither is node-xmpp-core JID anyway ( + other issues such as memory leaks and native module burden).

I plan to work on RFC 7622 compliance next.

[ChALkeR]

Tracking: nodejs/node#2798

[astro]

Fixed by #79