Re: [Mailman-Developers] Javascript Client for Mailman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 25.03.2015 um 07:51 schrieb Ana Badescu:
Another
*very* nice way to handle asynchronous behaviour in JS (and one the avoids callback hell) is the Promises paradigm. Promises are a native ES6 feature per-spec, but not all platforms support it. Node doesn't, but there's a drop-in polyfill[1] and a number of other libraries you could use.
The JS client should be able to do the things mailman.client can do, but that doesn't mean its internals need to be anything like mailman.client's. *Some* similarity to the Python version would be nice, but not to the extend that we do something in a way you normaly wouldn't in JS. The intended audience are folks who use JS, so I'd rather not have a client that runs on node but looks like Python. :-)
"All the functionality that Postorious does" sounds like your summer is *a lot* longer than mine is. :-) I definitely don't see that.
What you could do though is add an *optional* task to your timeline, building a *very small* and stripped down web ui proof of concept, with only a small handful of features that you can use to demonstrate how to integrate the client. But that shouldn't be worked on before anything else has been finished.
Cheers, Florian
[1] https://github.com/jakearchibald/es6-promise
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEcBAEBAgAGBQJVEsTAAAoJEEceGbPdavl7Vi8H/0+oj9soM2oRDHBYpnPZo4OG NSwobau3vKrmja/OU0lrXOwlYxfYo+WeQnmf17dlvJOk9zYqPCtSLT5emcV3gQjv vWgzBFwG2sXY0MM/rvfSS+CUIzpNPI+kdhOXriQxhkylBu4aDl8XCiII1xmry7u6 5aFzMygFuV6ixyZRUwriB+qbqvxYdQ+eFkW+LyBvk4y0fkjTEK0/9fXnghkc8fuq taYAbCnhpKZtO6hAsIgQoPPtuGDEqPq5VjjIU89JGeaRjxZ/LX/SOHh2thpgXhre JD+3W5FdziCp3qFijeQCVuK/fErEF1nevC5/wTeeW9fY7/ZOT5GhYCDs4i6EjkM= =3uJ7 -----END PGP SIGNATURE-----
Yes, I have used async.js before and it turned out easy and straight-forward. In another project I tried coffeescript which also solves this in an elegant manner but that's a whole another discussion :).
The JS client should be able to do the things mailman.client can do,
Fair enough!
Thanks for clearing this out, Ana
Florian Fuchs writes:
The intended audience are folks who use JS, so I'd rather not have a client that runs on node but looks like Python. :-)
+1
Florian addressed "attainability", but I'd like to say that I don't see that we need another Postorius. If you want to go in that direction, you'd have to address the question "why does this application want to (mostly) run disconnected?"
I think the answer is that it doesn't. It's quite reasonable for all of the logic in Postorius to be server-side. That's not to say that having it client-side wouldn't work just as well or maybe even a little bit better, but we already have Postorius. An alternative set of functionality *not* in Postorius (the user dashboard might be a good one) would be better, and an application that "needs" to run client-side to be sufficiently responsive would be the best showcase for your "javascript.client".
I understand what Florian is saying and I don't disagree, but let me offer an alternative perspective for discussion. Build the small app's UI first, and use that as a testbed use case for the javascript side API that you're building. APIs need use cases (consider how TCP/IP "rough consensus and running code" beat OSI's "a priori design and engineering" for internetworking). I don't know that this is a practical approach. Just sayin'.
On Thu, Mar 26, 2015 at 4:05 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
The Javascript client is actually a node.js module, and users will be able to use it as part of a node.js application which just as Postorious, is server-side. I'd like it *to not* run disconnected, but that would mean Postorious (a Django app) would have to be able to use a node.js module, which isn't possible at the moment :).
I understand what Florian is saying and I don't disagree, but let me
Bingo! That's what I was also thinking. However, we can set up proper test cases for each API, in Javascript as well. There is a large number of testing strategy modules that offer everything to set up a testing environment, stubs, mocks. I was also thinking how some university colleagues have begun a startup and they're offering an API to developers and they've already built API clients for a few web frameworks/languages. As part of their "marketing strategy" they're building proof of concept apps to showcase how the API clients are used and how their API is consumed.
I do agree with Florian, this would be a small fun project, *after the client is finished*, during what's left of or after the summer.
Cheers, Ana
Yes, I have used async.js before and it turned out easy and straight-forward. In another project I tried coffeescript which also solves this in an elegant manner but that's a whole another discussion :).
The JS client should be able to do the things mailman.client can do,
Fair enough!
Thanks for clearing this out, Ana
Florian Fuchs writes:
The intended audience are folks who use JS, so I'd rather not have a client that runs on node but looks like Python. :-)
+1
Florian addressed "attainability", but I'd like to say that I don't see that we need another Postorius. If you want to go in that direction, you'd have to address the question "why does this application want to (mostly) run disconnected?"
I think the answer is that it doesn't. It's quite reasonable for all of the logic in Postorius to be server-side. That's not to say that having it client-side wouldn't work just as well or maybe even a little bit better, but we already have Postorius. An alternative set of functionality *not* in Postorius (the user dashboard might be a good one) would be better, and an application that "needs" to run client-side to be sufficiently responsive would be the best showcase for your "javascript.client".
I understand what Florian is saying and I don't disagree, but let me offer an alternative perspective for discussion. Build the small app's UI first, and use that as a testbed use case for the javascript side API that you're building. APIs need use cases (consider how TCP/IP "rough consensus and running code" beat OSI's "a priori design and engineering" for internetworking). I don't know that this is a practical approach. Just sayin'.
On Thu, Mar 26, 2015 at 4:05 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
The Javascript client is actually a node.js module, and users will be able to use it as part of a node.js application which just as Postorious, is server-side. I'd like it *to not* run disconnected, but that would mean Postorious (a Django app) would have to be able to use a node.js module, which isn't possible at the moment :).
I understand what Florian is saying and I don't disagree, but let me
Bingo! That's what I was also thinking. However, we can set up proper test cases for each API, in Javascript as well. There is a large number of testing strategy modules that offer everything to set up a testing environment, stubs, mocks. I was also thinking how some university colleagues have begun a startup and they're offering an API to developers and they've already built API clients for a few web frameworks/languages. As part of their "marketing strategy" they're building proof of concept apps to showcase how the API clients are used and how their API is consumed.
I do agree with Florian, this would be a small fun project, *after the client is finished*, during what's left of or after the summer.
Cheers, Ana
participants (3)
-
Ana Badescu -
Florian Fuchs -
Stephen J. Turnbull