You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by dnwe <gi...@git.apache.org> on 2015/01/27 17:18:08 UTC
[GitHub] qpid-proton pull request: Initial draft of a node binding via swig...
GitHub user dnwe opened a pull request:
https://github.com/apache/qpid-proton/pull/5
Initial draft of a node binding via swig 3.x
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/dnwe/qpid-proton swig-for-nodejs
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-proton/pull/5.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5
----
commit 3062005a42337a3fbb2cc727714bc63183ae985d
Author: Dominic Evans <do...@uk.ibm.com>
Date: 2014-12-18T16:38:12Z
Initial draft of a node binding via swig 3.x
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: [GitHub] qpid-proton pull request: Initial draft of a node
binding via swig...
Posted by Rafael Schloming <rh...@alum.mit.edu>.
This looks like a pretty isolated change. If you want to pull it in prior
to 0.9, I would be in favor of getting it in sooner rather than later.
--Rafael
On Tue, Jan 27, 2015 at 11:18 AM, dnwe <gi...@git.apache.org> wrote:
> GitHub user dnwe opened a pull request:
>
> https://github.com/apache/qpid-proton/pull/5
>
> Initial draft of a node binding via swig 3.x
>
>
>
> You can merge this pull request into a Git repository by running:
>
> $ git pull https://github.com/dnwe/qpid-proton swig-for-nodejs
>
> Alternatively you can review and apply these changes as the patch at:
>
> https://github.com/apache/qpid-proton/pull/5.patch
>
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
>
> This closes #5
>
> ----
> commit 3062005a42337a3fbb2cc727714bc63183ae985d
> Author: Dominic Evans <do...@uk.ibm.com>
> Date: 2014-12-18T16:38:12Z
>
> Initial draft of a node binding via swig 3.x
>
> ----
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastructure@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
[GitHub] qpid-proton pull request: Initial draft of a node binding via swig...
Posted by dnwe <gi...@git.apache.org>.
Github user dnwe closed the pull request at:
https://github.com/apache/qpid-proton/pull/5
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[GitHub] qpid-proton pull request: Initial draft of a node binding via swig...
Posted by dnwe <gi...@git.apache.org>.
Github user dnwe closed the pull request at:
https://github.com/apache/qpid-proton/pull/5
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: [GitHub] qpid-proton pull request: Initial draft of a node
binding via swig...
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Tue, Jan 27, 2015 at 2:38 PM, Fraser Adams <fraser.adams@blueyonder.co.uk
> wrote:
> Hi Dominic,
> I guess that my main concern is the potential for confusion :-)
>
> I'm actually a bit curious/confused - when I took a peek at the patch
> there wasn't much in there and looked mostly makefile related, I was aware
> that swig 3.x had node/JavaScript support but how exactly are the binding
> working - i.e what do they *look* like.
>
> With the emscripten stuff the real effort wasn't actually so much about
> getting proton-c compiled and usable *as a C API* the actual send-async.c
> and recv-async.c were the first things I actually did and that only took a
> couple of weekends getting to know emscripten and Proton, but the main
> effort was getting a binding that was more idiomatically JavaScript (I hope
> I achieved that) - so that included all the stuff for serialising
> JavaScript Obects into the AMQP type system etc.
>
> If you look at the emscripten binding stuff that follows a "pattern" that
> actually looks pretty close to the Python binding in terms of trying to
> provide some higher level abstractions.
>
> Another world of complication was trying to get things working in a
> properly async. event driven way.
>
> I couldn't see anything like that in your patch, is that something that is
> just TBD, or have I just missed something (entirely possible).
>
At the risk of putting words in dominic's mouth, he indicated on IRC that
this part is TBD. My encouragement to bring it in is precisely because it's
small, isolated, and very quick to review. In general I think it is harder
to keep up with reviews when too much stuff accumulates on a single feature
branch.
> Please don't take this as me being critical - it's not intended to come
> across like that - it's just that I put a ton of effort into the emscripten
> based approach and I'm fairly keen for there to be (or at least for there
> to be an aspiration towards) some consistency.
>
> As you probably know the emscripten binding runs perfectly happily on
> Node.js albeit using a WebSocket transport hence scope for confusion.
>
> To be fair the WebSocket restriction is probably the biggest down-side of
> the emscripten approach with Node.js and it's on my TODO list. I guess it'd
> be good to compare the relative performance - I'd expect the Swig approach
> to run faster at present but that might change over time and the margin may
> well decrease - V8 hasn't yet implemented the asm.js optimisations and I
> noticed a huge performance difference on Firefox between my old FF24 and my
> more recent FF35, the latter properly ahead of time compiles asm.js and the
> performance seems to be creeping up on the Python bindings, which clearly
> are using native code.
>
> I'm sure that the emscripten stuff will always lag behind native and I
> personally think the two approaches are complementary rather than
> competing, but I'd definitely like to aspire to consistency (hope I'm not
> coming over as a bit precious - email isn't great for conveying some of
> this stuff).
>
> I'll happily get involved too, I'm a bit distracted on some other stuff at
> the mo. and I need to get my head around the Swig stuff so it probably
> won't be for a few weeks though.
>
FWIW, I'd also like to see consistency between the two bindings. I think
we'll always need a pure javascript version for browser support, but I can
see why people might like the native option for node, and I want to be able
to run the same code in both places unchanged.
--Rafael
Re: [GitHub] qpid-proton pull request: Initial draft of a node
binding via swig...
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Tue, Jan 27, 2015 at 4:03 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 01/27/2015 07:38 PM, Fraser Adams wrote:
>
>> Hi Dominic,
>> I guess that my main concern is the potential for confusion :-)
>>
>> I'm actually a bit curious/confused - when I took a peek at the patch
>> there wasn't much in there and looked mostly makefile related, I was
>> aware that swig 3.x had node/JavaScript support but how exactly are the
>> binding working - i.e what do they *look* like.
>>
>> With the emscripten stuff the real effort wasn't actually so much about
>> getting proton-c compiled and usable *as a C API* the actual
>> send-async.c and recv-async.c were the first things I actually did and
>> that only took a couple of weekends getting to know emscripten and
>> Proton, but the main effort was getting a binding that was more
>> idiomatically JavaScript (I hope I achieved that) - so that included all
>> the stuff for serialising JavaScript Obects into the AMQP type system etc.
>>
>> If you look at the emscripten binding stuff that follows a "pattern"
>> that actually looks pretty close to the Python binding in terms of
>> trying to provide some higher level abstractions.
>>
>> Another world of complication was trying to get things working in a
>> properly async. event driven way.
>>
>> I couldn't see anything like that in your patch, is that something that
>> is just TBD, or have I just missed something (entirely possible).
>>
>> Please don't take this as me being critical - it's not intended to come
>> across like that - it's just that I put a ton of effort into the
>> emscripten based approach and I'm fairly keen for there to be (or at
>> least for there to be an aspiration towards) some consistency.
>>
>> As you probably know the emscripten binding runs perfectly happily on
>> Node.js albeit using a WebSocket transport hence scope for confusion.
>>
>> To be fair the WebSocket restriction is probably the biggest down-side
>> of the emscripten approach with Node.js and it's on my TODO list. I
>> guess it'd be good to compare the relative performance - I'd expect the
>> Swig approach to run faster at present but that might change over time
>> and the margin may well decrease - V8 hasn't yet implemented the asm.js
>> optimisations and I noticed a huge performance difference on Firefox
>> between my old FF24 and my more recent FF35, the latter properly ahead
>> of time compiles asm.js and the performance seems to be creeping up on
>> the Python bindings, which clearly are using native code.
>>
>> I'm sure that the emscripten stuff will always lag behind native and I
>> personally think the two approaches are complementary rather than
>> competing, but I'd definitely like to aspire to consistency (hope I'm
>> not coming over as a bit precious - email isn't great for conveying some
>> of this stuff).
>>
>> I'll happily get involved too, I'm a bit distracted on some other stuff
>> at the mo. and I need to get my head around the Swig stuff so it
>> probably won't be for a few weeks though.
>>
>
> I agree that while both approaches are likely valuable and can both be
> supported, consistency is important. I would like to have in javascript
> something similar to the reactive engine api that is available in python,
> and have that runnable in node or in a browser without having to change
> code for different types of binding (other than at most the import/require).
>
+1
I think the reactive API is actually quite a natural fit for javascript as
pretty much everything else in javascript works that way already. This is
one of the reasons I have been working on building out a proper reactor in
C. I believe that whether via swig or via emscripten, the C reactor will
provide a very nice option for using proton from javascript.
--Rafael
Re: [GitHub] qpid-proton pull request: Initial draft of a node binding
via swig...
Posted by Gordon Sim <gs...@redhat.com>.
On 01/27/2015 07:38 PM, Fraser Adams wrote:
> Hi Dominic,
> I guess that my main concern is the potential for confusion :-)
>
> I'm actually a bit curious/confused - when I took a peek at the patch
> there wasn't much in there and looked mostly makefile related, I was
> aware that swig 3.x had node/JavaScript support but how exactly are the
> binding working - i.e what do they *look* like.
>
> With the emscripten stuff the real effort wasn't actually so much about
> getting proton-c compiled and usable *as a C API* the actual
> send-async.c and recv-async.c were the first things I actually did and
> that only took a couple of weekends getting to know emscripten and
> Proton, but the main effort was getting a binding that was more
> idiomatically JavaScript (I hope I achieved that) - so that included all
> the stuff for serialising JavaScript Obects into the AMQP type system etc.
>
> If you look at the emscripten binding stuff that follows a "pattern"
> that actually looks pretty close to the Python binding in terms of
> trying to provide some higher level abstractions.
>
> Another world of complication was trying to get things working in a
> properly async. event driven way.
>
> I couldn't see anything like that in your patch, is that something that
> is just TBD, or have I just missed something (entirely possible).
>
> Please don't take this as me being critical - it's not intended to come
> across like that - it's just that I put a ton of effort into the
> emscripten based approach and I'm fairly keen for there to be (or at
> least for there to be an aspiration towards) some consistency.
>
> As you probably know the emscripten binding runs perfectly happily on
> Node.js albeit using a WebSocket transport hence scope for confusion.
>
> To be fair the WebSocket restriction is probably the biggest down-side
> of the emscripten approach with Node.js and it's on my TODO list. I
> guess it'd be good to compare the relative performance - I'd expect the
> Swig approach to run faster at present but that might change over time
> and the margin may well decrease - V8 hasn't yet implemented the asm.js
> optimisations and I noticed a huge performance difference on Firefox
> between my old FF24 and my more recent FF35, the latter properly ahead
> of time compiles asm.js and the performance seems to be creeping up on
> the Python bindings, which clearly are using native code.
>
> I'm sure that the emscripten stuff will always lag behind native and I
> personally think the two approaches are complementary rather than
> competing, but I'd definitely like to aspire to consistency (hope I'm
> not coming over as a bit precious - email isn't great for conveying some
> of this stuff).
>
> I'll happily get involved too, I'm a bit distracted on some other stuff
> at the mo. and I need to get my head around the Swig stuff so it
> probably won't be for a few weeks though.
I agree that while both approaches are likely valuable and can both be
supported, consistency is important. I would like to have in javascript
something similar to the reactive engine api that is available in
python, and have that runnable in node or in a browser without having to
change code for different types of binding (other than at most the
import/require).
I also am busy at present with python, but hope to have some time soon
to take a look at javascript also.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: [GitHub] qpid-proton pull request: Initial draft of a node binding
via swig...
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Dominic,
I guess that my main concern is the potential for confusion :-)
I'm actually a bit curious/confused - when I took a peek at the patch
there wasn't much in there and looked mostly makefile related, I was
aware that swig 3.x had node/JavaScript support but how exactly are the
binding working - i.e what do they *look* like.
With the emscripten stuff the real effort wasn't actually so much about
getting proton-c compiled and usable *as a C API* the actual
send-async.c and recv-async.c were the first things I actually did and
that only took a couple of weekends getting to know emscripten and
Proton, but the main effort was getting a binding that was more
idiomatically JavaScript (I hope I achieved that) - so that included all
the stuff for serialising JavaScript Obects into the AMQP type system etc.
If you look at the emscripten binding stuff that follows a "pattern"
that actually looks pretty close to the Python binding in terms of
trying to provide some higher level abstractions.
Another world of complication was trying to get things working in a
properly async. event driven way.
I couldn't see anything like that in your patch, is that something that
is just TBD, or have I just missed something (entirely possible).
Please don't take this as me being critical - it's not intended to come
across like that - it's just that I put a ton of effort into the
emscripten based approach and I'm fairly keen for there to be (or at
least for there to be an aspiration towards) some consistency.
As you probably know the emscripten binding runs perfectly happily on
Node.js albeit using a WebSocket transport hence scope for confusion.
To be fair the WebSocket restriction is probably the biggest down-side
of the emscripten approach with Node.js and it's on my TODO list. I
guess it'd be good to compare the relative performance - I'd expect the
Swig approach to run faster at present but that might change over time
and the margin may well decrease - V8 hasn't yet implemented the asm.js
optimisations and I noticed a huge performance difference on Firefox
between my old FF24 and my more recent FF35, the latter properly ahead
of time compiles asm.js and the performance seems to be creeping up on
the Python bindings, which clearly are using native code.
I'm sure that the emscripten stuff will always lag behind native and I
personally think the two approaches are complementary rather than
competing, but I'd definitely like to aspire to consistency (hope I'm
not coming over as a bit precious - email isn't great for conveying some
of this stuff).
I'll happily get involved too, I'm a bit distracted on some other stuff
at the mo. and I need to get my head around the Swig stuff so it
probably won't be for a few weeks though.
Regards,
Frase
On 27/01/15 19:07, dnwe wrote:
> GitHub user dnwe reopened a pull request:
>
> https://github.com/apache/qpid-proton/pull/5
>
> Initial draft of a node binding via swig 3.x
>
> As an alternative to the emscripten-based javascript bindings, swig 3.x now has native support for generating node wrappers, so it makes sense to offer them as a further alternative entry point (alongside the emscripten one) that is closer to the existing swig bindings for the other languages.
>
> You can merge this pull request into a Git repository by running:
>
> $ git pull https://github.com/dnwe/qpid-proton swig-for-nodejs
>
> Alternatively you can review and apply these changes as the patch at:
>
> https://github.com/apache/qpid-proton/pull/5.patch
>
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
>
> This closes #5
>
> ----
> commit 3062005a42337a3fbb2cc727714bc63183ae985d
> Author: Dominic Evans <do...@uk.ibm.com>
> Date: 2014-12-18T16:38:12Z
>
> Initial draft of a node binding via swig 3.x
>
> ----
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastructure@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[GitHub] qpid-proton pull request: Initial draft of a node binding via swig...
Posted by dnwe <gi...@git.apache.org>.
GitHub user dnwe reopened a pull request:
https://github.com/apache/qpid-proton/pull/5
Initial draft of a node binding via swig 3.x
As an alternative to the emscripten-based javascript bindings, swig 3.x now has native support for generating node wrappers, so it makes sense to offer them as a further alternative entry point (alongside the emscripten one) that is closer to the existing swig bindings for the other languages.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/dnwe/qpid-proton swig-for-nodejs
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-proton/pull/5.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5
----
commit 3062005a42337a3fbb2cc727714bc63183ae985d
Author: Dominic Evans <do...@uk.ibm.com>
Date: 2014-12-18T16:38:12Z
Initial draft of a node binding via swig 3.x
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[GitHub] qpid-proton pull request: Initial draft of a node binding via swig...
Posted by dnwe <gi...@git.apache.org>.
Github user dnwe commented on the pull request:
https://github.com/apache/qpid-proton/pull/5#issuecomment-71707921
Pushed as d564ddcfbfa3901cafe823ead283d091db1157b7
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org