Re: [Mailman-Developers] Javascript Client for Mailman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 25.03.2015 um 07:51 schrieb Ana Badescu:
Hello,
While writing my proposal I came across 2 important issues related to the Javascript Client for the Mailman project that have yet to be raised:
- What I initially had in mind, was to build a Mailman client in Javascript that provides the same API and functionality that the current one in Python does. The Python client API can be fully mimicked using a number of design patterns even though Javascript doesn't offer properties capability for example. However, node.js modules tend to take advantage of Javascript's asynchronous nature and have adopted sort of a standard practice to achieve it: it's called error-first callbacks, and most if not all APIs enforce it. You can read about it here http://thenodeway.io/posts/understanding-error-first-callbacks/ and here https://docs.nodejitsu.com/articles/errors/what-are-the-error-conventi ons
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.
This boils down if we want to provide a client API that adopts the node.js conventions and works the same way most modules do or do we want to offer something almost similar to the current Python client API. There's a lot more to be said on this matter (for eg: callbacks being the reason why "callback-hell" exists) but I'd like to get your input first.
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. :-)
- I'd also like to make part of the project, a node.js application that uses the Mailman Javascript client and offers all the functionality Postorious does. Is that a good idea? This doesn't make the scope of the project too large or unattainable.
"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-----
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.
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,
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. :-)
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
- I'd also like to make part of the project, a node.js application that uses the Mailman Javascript client and offers all the functionality Postorious does. Is that a good idea?
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".
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.
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:
Florian Fuchs writes: If you want to go in that direction, you'd have to address the question "why does this application want to (mostly) run disconnected?"
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
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'.
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