Re: [Mailman-Developers] Javascript Client for Mailman
At 01:51 AM 3/25/2015, Ana Badescu wrote: 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: 2. 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. Please remember that anything you develop should be accessible to disabled persons. This is possible with JAVA generally, but means some planning, using the right libraries etc. Dave David Andrews and long white cane Harry. E-Mail: dandr...@visi.com or david.andr...@nfbnet.org ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Javascript Client for Mailman
Hello, Well, thanks Stephen for adding and clarifying things. Actually, I have also submitted a proposal on the same and have been doing a lot of research work on this for the past few weeks. So, I added up on the callback stuff. Actually, I felt that it would be lots of work if someone want to have a entire postorius like thing for node as part of the GSoC project. So, for the time focusing on the port will be the best thing. So, I agree with Florian here. As far as the reasons you have suggested for not commenting, I will go with (c) option and the reason being I was lacking on the term Student but now things are more clear :-) On Thu, Mar 26, 2015 at 7:21 AM, Stephen J. Turnbull step...@xemacs.org wrote: Ankush Sharma writes: I cannot comment on this as I am a student just like you. First, thank you very much for commenting in the first place! Students helping each other is one of the most exciting aspects of GSoC. But I think you misunderstand student in the context of GSoC. It's an accounting term. Students get paid, mentors get tired, er, T-shirts, that's it! Mentors get T-shirts! Other than that, we're all Mailman developers. You can and should comment on anything where you have an opinion. Some developers have more experience and skills, some have a natural talent for programming or design or building UIs and others don't have any of the above but need a feature or bugfix, and nobody else seems to want to do it. The good reasons for not giving your opinion are (a) you don't have one (a common reason for those with less experience in the project), (b) somebody's already expressed pretty much the same opinion (in cases where values differ, you might even add a +1 here), and (c) you're waiting for somebody else to comment first for some reason. That's a little bit oversimplified, but it's important. I don't know if it's made explicit in the GSoC handbooks, but if you get a chance to talk to Carol or Cat you'll hear that one of the things they enjoy most is hearing about students who become mentors. That's a core value in GSoC: the kind of professional growth that turns students into teachers. And it happens in just one or two years for many students. New members normally don't get that experience in a company (unless you're running it :-). They also hear stories about how that assumption of responsibility carries over to the new mentor's school and employment opportunities. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Javascript Client for Mailman
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: 1. 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-conventions 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. 2. 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. Thank you, Ana ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
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: 1. 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. :-) 2. 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- ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Javascript Client for Mailman
Hey, On Wed, Mar 25, 2015 at 12:21 PM, Ana Badescu anabee.em...@gmail.com wrote: 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: 1. 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-conventions 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. Since, you will be working with Node,js ; you cannot get away from callbacks. This JavaScript port is not a simple port :) 2. 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. I cannot comment on this as I am a student just like you. Thank you, Ana ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/ankush.sharma.ece12%40itbhu.ac.in Security Policy: http://wiki.list.org/x/QIA9 Thanks, Ankush Sharma ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Javascript Client for Mailman
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 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Javascript Client for Mailman
Ankush Sharma writes: I cannot comment on this as I am a student just like you. First, thank you very much for commenting in the first place! Students helping each other is one of the most exciting aspects of GSoC. But I think you misunderstand student in the context of GSoC. It's an accounting term. Students get paid, mentors get tired, er, T-shirts, that's it! Mentors get T-shirts! Other than that, we're all Mailman developers. You can and should comment on anything where you have an opinion. Some developers have more experience and skills, some have a natural talent for programming or design or building UIs and others don't have any of the above but need a feature or bugfix, and nobody else seems to want to do it. The good reasons for not giving your opinion are (a) you don't have one (a common reason for those with less experience in the project), (b) somebody's already expressed pretty much the same opinion (in cases where values differ, you might even add a +1 here), and (c) you're waiting for somebody else to comment first for some reason. That's a little bit oversimplified, but it's important. I don't know if it's made explicit in the GSoC handbooks, but if you get a chance to talk to Carol or Cat you'll hear that one of the things they enjoy most is hearing about students who become mentors. That's a core value in GSoC: the kind of professional growth that turns students into teachers. And it happens in just one or two years for many students. New members normally don't get that experience in a company (unless you're running it :-). They also hear stories about how that assumption of responsibility carries over to the new mentor's school and employment opportunities. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Javascript Client for Mailman
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 2. 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'. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Javascript Client for Mailman
On Thu, Mar 26, 2015 at 4:05 AM, Stephen J. Turnbull step...@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 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Javascript Client for Mailman
Ana Badescu writes: 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. Oops, that's right, the REST API normally isn't exposed except to localhost. My bad. 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. My point is that no, you can't. If you don't have real use cases, you will write tests that don't matter, and you will fail to cover things that some real use case depends on. Often enough, those things can be really basic, and embarrass both your programmer's pride and your schedule. Both strategies, a priori (here's my API definition, make sure it works) and use-case-based (here's my use case, make sure the API can implement it) are necessary. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
