Re: [Phpmyadmin-devel] GSoC Project - AJAX Error Reporting
Hi Rouslan, Thanks for replying. I was unable to reply properly using my SourceForge account. I have worked with a few mailing lists like Google Groups, but this one seemed different to me. I didn't even get emails when you people replied on this thread because I had my Digest Mode On, thus I didn't have an option to Reply to All. I will be formatting manually for this time only, as I have no email to reply to. (Didn't wanna spoil the reply format) Rouslan Placella wrote:
Hi Abhishek,
have you got a live demo of this application that I could try?
Yes, you can try it online at http://faceinbook.co.nr/flowork/home.html.
From your email, I'm getting the feeling that you didn't fully understand where the different components of the system will reside...
Yeah, I got it a bit wrong on the first go. But on reading the idea again I understood what exactly it is about.
The server-side component of this system will not be for the users of phpMyAdmin or administrators of individual phpMyAdmin installations, it will, instead, be used by the members of the phpMyAdmin development team[0] to globally diagnose issues.
I thought a client-side component for handling errors as well as one for diagnosing issues was suggested. But actually the suggestion was for a client-side component for sending errors to a server-side component with the data containing nothing that concerns the user about his/her privacy. Thus there is no need of encryption as you said, because the data contains no sensitive information. And also as you wrote that there is no means to check if a request is valid, and hence no need for checking for authentication. I would be happy to implement what you suggested about restricting the number of requests per IP to prevent the defacing of the server-system. Also I will be more than pleased to work on the server-side part to allow the phpMyAdmin developers to analyze and diagnose the errors. Also to prevent the back-end from attacks such as DoS you suggested a global limit on the number of requests. It seems easy to implement but will play an important role against DoS attacks. I will reply back after I work out a plan for the server-side interface and functioning for comments from you all. Rouslan Placella wrote:
The wiki is pretty comprehensive on the matter. Do you have a more specific question?
Yes, is there a place where I can upload a draft of my application for my mentor to review it? If not, is posting it to the mailing list fine?
On 04/15/2013 07:16 PM, Abhishek Kandoi wrote:
Hi Rouslan,
Thanks for replying. I was unable to reply properly using my SourceForge account. I have worked with a few mailing lists like Google Groups, but this one seemed different to me. I didn't even get emails when you people replied on this thread because I had my Digest Mode On, thus I didn't have an option to Reply to All.
I will be formatting manually for this time only, as I have no email to reply to. (Didn't wanna spoil the reply format)
Rouslan Placella wrote:
Hi Abhishek,
have you got a live demo of this application that I could try?
Yes, you can try it online at http://faceinbook.co.nr/flowork/home.html.
Out of curiosity, was the app a college project? Also, I would like to hear from you about what you think are the shortcomings of your implementation. Would you do anything differently if you had to do it again from scratch?
From your email, I'm getting the feeling that you didn't fully understand where the different components of the system will reside...
Yeah, I got it a bit wrong on the first go. But on reading the idea again I understood what exactly it is about.
The server-side component of this system will not be for the users of phpMyAdmin or administrators of individual phpMyAdmin installations, it will, instead, be used by the members of the phpMyAdmin development team[0] to globally diagnose issues.
I thought a client-side component for handling errors as well as one for diagnosing issues was suggested. But actually the suggestion was for a client-side component for sending errors to a server-side component with the data containing nothing that concerns the user about his/her privacy. Thus there is no need of encryption as you said, because the data contains no sensitive information.
And also as you wrote that there is no means to check if a request is valid, and hence no need for checking for authentication.
I would be happy to implement what you suggested about restricting the number of requests per IP to prevent the defacing of the server-system. Also I will be more than pleased to work on the server-side part to allow the phpMyAdmin developers to analyze and diagnose the errors.
Also to prevent the back-end from attacks such as DoS you suggested a global limit on the number of requests. It seems easy to implement but will play an important role against DoS attacks.
I will reply back after I work out a plan for the server-side interface and functioning for comments from you all.
Rouslan Placella wrote:
The wiki is pretty comprehensive on the matter. Do you have a more specific question?
Yes, is there a place where I can upload a draft of my application for my mentor to review it? If not, is posting it to the mailing list fine?
Not that I know of. You can post to the mailing list, but your draft will be visible to other gsoc candidates. Bye, Rouslan
On 4/16/13, Rouslan Placella <rouslan@placella.com> wrote:
On 04/15/2013 07:16 PM, Abhishek Kandoi wrote:
Hi Rouslan,
Thanks for replying. I was unable to reply properly using my SourceForge account. I have worked with a few mailing lists like Google Groups, but this one seemed different to me. I didn't even get emails when you people replied on this thread because I had my Digest Mode On, thus I didn't have an option to Reply to All.
I will be formatting manually for this time only, as I have no email to reply to. (Didn't wanna spoil the reply format)
Rouslan Placella wrote:
Hi Abhishek,
have you got a live demo of this application that I could try?
Yes, you can try it online at http://faceinbook.co.nr/flowork/home.html.
Out of curiosity, was the app a college project?
No. I made it as an assignment given to me at SDSLabs(a group of like minded students developing open source) after a Lecture on basic PHP. I had to attend it although I knew everything that was taught. I have been using PHP for the past few years and I really enjoy it.
Also, I would like to hear from you about what you think are the shortcomings of your implementation. Would you do anything differently if you had to do it again from scratch?
According to me there are a few shortcomings in my implementation. If I had to develop it again from scratch, I would like to work on the following features: 1) Security implementation(escaping html) to prevent XSS attacks. 2) Adding Modularity to the code both on client-side and on server-side. 3) Limiting the number of unsuccessful login attempts to prevent easy brute-force based account cracking. 4) Use of Enter button for Login In and Sign Up forms to enhance user experience(the current one lacks this UX feature). 5) Basic animations on deletion of a to-do. 6) Drag and drop functionality for deleting a to-do. 7) Responsive Design for the to-do list (the current one has too small images on a smartphone). 8) Using bcrypt instead of sha1 for password encryption. 9) Ability to nest to-do descriptions and summaries. I have these ideas in my mind for now. Will let you know more, if you are interested.
From your email, I'm getting the feeling that you didn't fully understand where the different components of the system will reside...
Yeah, I got it a bit wrong on the first go. But on reading the idea again I understood what exactly it is about.
The server-side component of this system will not be for the users of phpMyAdmin or administrators of individual phpMyAdmin installations, it will, instead, be used by the members of the phpMyAdmin development team[0] to globally diagnose issues.
I thought a client-side component for handling errors as well as one for diagnosing issues was suggested. But actually the suggestion was for a client-side component for sending errors to a server-side component with the data containing nothing that concerns the user about his/her privacy. Thus there is no need of encryption as you said, because the data contains no sensitive information.
And also as you wrote that there is no means to check if a request is valid, and hence no need for checking for authentication.
I would be happy to implement what you suggested about restricting the number of requests per IP to prevent the defacing of the server-system. Also I will be more than pleased to work on the server-side part to allow the phpMyAdmin developers to analyze and diagnose the errors.
Also to prevent the back-end from attacks such as DoS you suggested a global limit on the number of requests. It seems easy to implement but will play an important role against DoS attacks.
I will reply back after I work out a plan for the server-side interface and functioning for comments from you all.
Rouslan Placella wrote:
The wiki is pretty comprehensive on the matter. Do you have a more specific question?
Yes, is there a place where I can upload a draft of my application for my mentor to review it? If not, is posting it to the mailing list fine?
Not that I know of. You can post to the mailing list, but your draft will be visible to other gsoc candidates.
Ok. Thanks for the information.
Bye, Rouslan
I was wondering if you can tell me about some of the shortcomings that you found in my webapp. I can teach me a lesson and I can learn something new from it and improve in my future projects. On Wed, Apr 17, 2013 at 3:07 AM, Abhishek Kandoi <abhikandoi2000@gmail.com>wrote:
On 4/16/13, Rouslan Placella <rouslan@placella.com> wrote:
On 04/15/2013 07:16 PM, Abhishek Kandoi wrote:
Hi Rouslan,
Thanks for replying. I was unable to reply properly using my SourceForge account. I have worked with a few mailing lists like Google Groups, but this one seemed different to me. I didn't even get emails when you people replied on this thread because I had my Digest Mode On, thus I didn't have an option to Reply to All.
I will be formatting manually for this time only, as I have no email to reply to. (Didn't wanna spoil the reply format)
Rouslan Placella wrote:
Hi Abhishek,
have you got a live demo of this application that I could try?
Yes, you can try it online at http://faceinbook.co.nr/flowork/home.html .
Out of curiosity, was the app a college project?
No. I made it as an assignment given to me at SDSLabs(a group of like minded students developing open source) after a Lecture on basic PHP. I had to attend it although I knew everything that was taught. I have been using PHP for the past few years and I really enjoy it.
Also, I would like to hear from you about what you think are the shortcomings of your implementation. Would you do anything differently if you had to do it again from scratch?
According to me there are a few shortcomings in my implementation. If I had to develop it again from scratch, I would like to work on the following features:
1) Security implementation(escaping html) to prevent XSS attacks. 2) Adding Modularity to the code both on client-side and on server-side. 3) Limiting the number of unsuccessful login attempts to prevent easy brute-force based account cracking. 4) Use of Enter button for Login In and Sign Up forms to enhance user experience(the current one lacks this UX feature). 5) Basic animations on deletion of a to-do. 6) Drag and drop functionality for deleting a to-do. 7) Responsive Design for the to-do list (the current one has too small images on a smartphone). 8) Using bcrypt instead of sha1 for password encryption. 9) Ability to nest to-do descriptions and summaries.
I have these ideas in my mind for now. Will let you know more, if you are interested.
From your email, I'm getting the feeling that you didn't fully understand where the different components of the system will reside...
Yeah, I got it a bit wrong on the first go. But on reading the idea again I understood what exactly it is about.
The server-side component of this system will not be for the users of phpMyAdmin or administrators of individual phpMyAdmin installations, it will, instead, be used by the members of the phpMyAdmin development team[0] to globally diagnose issues.
I thought a client-side component for handling errors as well as one for diagnosing issues was suggested. But actually the suggestion was for a client-side component for sending errors to a server-side component with the data containing nothing that concerns the user about his/her privacy. Thus there is no need of encryption as you said, because the data contains no sensitive information.
And also as you wrote that there is no means to check if a request is valid, and hence no need for checking for authentication.
I would be happy to implement what you suggested about restricting the number of requests per IP to prevent the defacing of the server-system. Also I will be more than pleased to work on the server-side part to allow the phpMyAdmin developers to analyze and diagnose the errors.
Also to prevent the back-end from attacks such as DoS you suggested a global limit on the number of requests. It seems easy to implement but will play an important role against DoS attacks.
I will reply back after I work out a plan for the server-side interface and functioning for comments from you all.
Rouslan Placella wrote:
The wiki is pretty comprehensive on the matter. Do you have a more specific question?
Yes, is there a place where I can upload a draft of my application for my mentor to review it? If not, is posting it to the mailing list fine?
Not that I know of. You can post to the mailing list, but your draft will be visible to other gsoc candidates.
Ok. Thanks for the information.
Bye, Rouslan
-- Abhishek Kandoi First Year, Computer Science and Engineering Indian Institute of Technology Roorkee About Me : about.me/kandoiabhi
There was something I wanted to know about. Would it be better to show an alert on the client side when an error which can impact the client side system occurs? Or as per my opinion we can simply create a custom modal box to show only those errors which affect the client-side system badly in a simple yet nice manner. Something like "Ops something went wrong, it may affect your working. Want to send a detailed error report to the developers of phpMyAdmin". This way we can get a detailed report from the user for really bad errors. Hence helping our developers to better understand the possible cause of the error, and hence better diagnose it. We can encourage clients to send a bit descriptive error report which may contain what all they did which resulted in a particular error. Tackling and fixing bugs would become easier this way. Also I would request you to refine my idea so that I can set particular goals for this project. Some more ideas from your side would be really helpful. On Tue, Apr 16, 2013 at 3:15 AM, Rouslan Placella <rouslan@placella.com>wrote:
On 04/15/2013 07:16 PM, Abhishek Kandoi wrote:
Hi Rouslan,
Thanks for replying. I was unable to reply properly using my SourceForge account. I have worked with a few mailing lists like Google Groups, but this one seemed different to me. I didn't even get emails when you people replied on this thread because I had my Digest Mode On, thus I didn't have an option to Reply to All.
I will be formatting manually for this time only, as I have no email to reply to. (Didn't wanna spoil the reply format)
Rouslan Placella wrote:
Hi Abhishek,
have you got a live demo of this application that I could try?
Yes, you can try it online at http://faceinbook.co.nr/flowork/home.html.
Out of curiosity, was the app a college project?
Also, I would like to hear from you about what you think are the shortcomings of your implementation. Would you do anything differently if you had to do it again from scratch?
From your email, I'm getting the feeling that you didn't fully understand where the different components of the system will reside...
Yeah, I got it a bit wrong on the first go. But on reading the idea again I understood what exactly it is about.
The server-side component of this system will not be for the users of phpMyAdmin or administrators of individual phpMyAdmin installations, it will, instead, be used by the members of the phpMyAdmin development team[0] to globally diagnose issues.
I thought a client-side component for handling errors as well as one for diagnosing issues was suggested. But actually the suggestion was for a client-side component for sending errors to a server-side component with the data containing nothing that concerns the user about his/her privacy. Thus there is no need of encryption as you said, because the data contains no sensitive information.
And also as you wrote that there is no means to check if a request is valid, and hence no need for checking for authentication.
I would be happy to implement what you suggested about restricting the number of requests per IP to prevent the defacing of the server-system. Also I will be more than pleased to work on the server-side part to allow the phpMyAdmin developers to analyze and diagnose the errors.
Also to prevent the back-end from attacks such as DoS you suggested a global limit on the number of requests. It seems easy to implement but will play an important role against DoS attacks.
I will reply back after I work out a plan for the server-side interface and functioning for comments from you all.
Rouslan Placella wrote:
The wiki is pretty comprehensive on the matter. Do you have a more specific question?
Yes, is there a place where I can upload a draft of my application for my mentor to review it? If not, is posting it to the mailing list fine?
Not that I know of. You can post to the mailing list, but your draft will be visible to other gsoc candidates.
Bye, Rouslan
------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Abhishek Kandoi First Year, Computer Science and Engineering Indian Institute of Technology Roorkee About Me : about.me/kandoiabhi
On 04/20/2013 04:29 PM, Abhishek Kandoi wrote:
There was something I wanted to know about. Would it be better to show an alert on the client side when an error which can impact the client side system occurs? Or as per my opinion we can simply create a custom modal box to show only those errors which affect the client-side system badly in a simple yet nice manner. Something like "Ops something went wrong, it may affect your working. Want to send a detailed error report to the developers of phpMyAdmin".
Dialogs for this feature should not be modal as, IMO, that would be too intrusive.
This way we can get a detailed report from the user for really bad errors. Hence helping our developers to better understand the possible cause of the error, and hence better diagnose it. We can encourage clients to send a bit descriptive error report which may contain what all they did which resulted in a particular error. Tackling and fixing bugs would become easier this way.
Also I would request you to refine my idea so that I can set particular goals for this project. Some more ideas from your side would be really helpful.
Refining the idea is your job, not ours. Oh, and we use bottom posting on this mailing list... Bye, Rouslan
On Tue, Apr 16, 2013 at 3:15 AM, Rouslan Placella <rouslan@placella.com <mailto:rouslan@placella.com>> wrote:
On 04/15/2013 07:16 PM, Abhishek Kandoi wrote: > Hi Rouslan, > > Thanks for replying. I was unable to reply properly using my SourceForge account. I have worked with a few mailing lists like Google Groups, but this one seemed different to me. I didn't even get emails when you people replied on this thread because I had my Digest Mode On, thus I didn't have an option to Reply to All. > > I will be formatting manually for this time only, as I have no email to reply to. (Didn't wanna spoil the reply format) > > Rouslan Placella wrote: > >> Hi Abhishek, >> >> have you got a live demo of this application that I could try? > > Yes, you can try it online at http://faceinbook.co.nr/flowork/home.html.
Out of curiosity, was the app a college project?
Also, I would like to hear from you about what you think are the shortcomings of your implementation. Would you do anything differently if you had to do it again from scratch?
>> From your email, I'm getting the feeling that you didn't fully >> understand where the different components of the system will reside... > > Yeah, I got it a bit wrong on the first go. But on reading the idea again I understood what exactly it is about. > > >> The server-side component of this system will not be for the users of >> phpMyAdmin or administrators of individual phpMyAdmin installations, it >> will, instead, be used by the members of the phpMyAdmin development >> team[0] to globally diagnose issues. > > I thought a client-side component for handling errors as well as one for diagnosing issues was suggested. But actually the suggestion was for a client-side component for sending errors to a server-side component with the data containing nothing that concerns the user about his/her privacy. Thus there is no need of encryption as you said, because the data contains no sensitive information. > > > And also as you wrote that there is no means to check if a request is valid, and hence no need for checking for authentication. > > > I would be happy to implement what you suggested about restricting the number of requests per IP to prevent the defacing of the server-system. Also I will be more than pleased to work on the server-side part to allow the phpMyAdmin developers to analyze and diagnose the errors. > > > Also to prevent the back-end from attacks such as DoS you suggested a global limit on the number of requests. It seems easy to implement but will play an important role against DoS attacks. > > > I will reply back after I work out a plan for the server-side interface and functioning for comments from you all. > > > Rouslan Placella wrote: > >> The wiki is pretty comprehensive on the matter. Do you have a more >> specific question? > > Yes, is there a place where I can upload a draft of my application for my mentor to review it? If not, is posting it to the mailing list fine?
Not that I know of. You can post to the mailing list, but your draft will be visible to other gsoc candidates.
Bye, Rouslan
On Sat, Apr 20, 2013 at 11:34 PM, Rouslan Placella <rouslan@placella.com>wrote:
On 04/20/2013 04:29 PM, Abhishek Kandoi wrote:
There was something I wanted to know about. Would it be better to show an alert on the client side when an error which can impact the client side system occurs? Or as per my opinion we can simply create a custom modal box to show only those errors which affect the client-side system badly in a simple yet nice manner. Something like "Ops something went wrong, it may affect your working. Want to send a detailed error report to the developers of phpMyAdmin".
Dialogs for this feature should not be modal as, IMO, that would be too intrusive.
Got it, this would disrupt their working and may even make a bad impression of intrusion.
This way we can get a detailed report from the user for really bad errors. Hence helping our developers to better understand the possible cause of the error, and hence better diagnose it. We can encourage clients to send a bit descriptive error report which may contain what all they did which resulted in a particular error. Tackling and fixing bugs would become easier this way.
Also I would request you to refine my idea so that I can set particular goals for this project. Some more ideas from your side would be really helpful.
Refining the idea is your job, not ours.
Sure, thanks for telling about this.
Oh, and we use bottom posting on this mailing list...
Sorry, but I didn't understand what you want to convey. I am doing it wrong? Please guide me if yes. Ok, so here is what I have thought this far. The client-side system would be behaving in the background without any disturbance to the client. The client-side system will send any Ajax Related error to our server-side system where the error will be stored in a database according to its type and the predicted level of problem that it can cause to the client-side system. Errors reported will contain no information about the client hence protecting their privacy. It would also be devoid of any kind of sensitive information which could possibly be hacked over a network hence removing the need for an encryption system. At the server-side there would be a web-interface that will allow phpMyAdmin developers to diagnose errors related to Ajax. The system will provide all the information related to an error for the developers to look upon (I would be documenting both the client and server-side error system at the end of the GSoC). The documentation will also provide some information related to common errors that may occur on the client-side, thus helping them in the process of diagnosis. The server-side web-interface would comprise of a simple left-side navigation menu for easy access to various locations on the website. The home screen would provide an overview of the recent errors that were added to the database and latest discussion by various developers on popular errors. Then there would be a functionality to directly forward bug reports to the phpMyAdmin bug tracker. Also as suggested on the ideas page there would be a functionality to search the database for specific types of errors based on their type, how frequently they occur. Moreover I was thinking of a small wiki for the error system so that a developer who has figured out the cause of a particular error can then document the problem to help others in fixing similar errors. This way other developers will be able to search the wiki for errors similar to one they are working on based on some tags(maybe), and hence fix them without loss of valuable time. What do you think about it? Please comment.
Bye, Rouslan
On Tue, Apr 16, 2013 at 3:15 AM, Rouslan Placella <rouslan@placella.com <mailto:rouslan@placella.com>> wrote:
On 04/15/2013 07:16 PM, Abhishek Kandoi wrote: > Hi Rouslan, > > Thanks for replying. I was unable to reply properly using my SourceForge account. I have worked with a few mailing lists like Google Groups, but this one seemed different to me. I didn't even get emails when you people replied on this thread because I had my Digest Mode On, thus I didn't have an option to Reply to All. > > I will be formatting manually for this time only, as I have no email to reply to. (Didn't wanna spoil the reply format) > > Rouslan Placella wrote: > >> Hi Abhishek, >> >> have you got a live demo of this application that I could try? > > Yes, you can try it online at http://faceinbook.co.nr/flowork/home.html.
Out of curiosity, was the app a college project?
Also, I would like to hear from you about what you think are the shortcomings of your implementation. Would you do anything differently if you had to do it again from scratch?
>> From your email, I'm getting the feeling that you didn't fully >> understand where the different components of the system will reside... > > Yeah, I got it a bit wrong on the first go. But on reading the idea again I understood what exactly it is about. > > >> The server-side component of this system will not be for the users of >> phpMyAdmin or administrators of individual phpMyAdmin installations, it >> will, instead, be used by the members of the phpMyAdmin development >> team[0] to globally diagnose issues. > > I thought a client-side component for handling errors as well as one for diagnosing issues was suggested. But actually the suggestion was for a client-side component for sending errors to a server-side component with the data containing nothing that concerns the user about his/her privacy. Thus there is no need of encryption as you said, because the data contains no sensitive information. > > > And also as you wrote that there is no means to check if a request is valid, and hence no need for checking for authentication. > > > I would be happy to implement what you suggested about restricting the number of requests per IP to prevent the defacing of the server-system. Also I will be more than pleased to work on the server-side part to allow the phpMyAdmin developers to analyze and diagnose the errors. > > > Also to prevent the back-end from attacks such as DoS you suggested a global limit on the number of requests. It seems easy to implement but will play an important role against DoS attacks. > > > I will reply back after I work out a plan for the server-side interface and functioning for comments from you all. > > > Rouslan Placella wrote: > >> The wiki is pretty comprehensive on the matter. Do you have a more >> specific question? > > Yes, is there a place where I can upload a draft of my application for my mentor to review it? If not, is posting it to the mailing list fine?
Not that I know of. You can post to the mailing list, but your draft will be visible to other gsoc candidates.
Bye, Rouslan
------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Abhishek Kandoi First Year, Computer Science and Engineering Indian Institute of Technology Roorkee About Me : about.me/kandoiabhi
On 04/20/2013 08:24 PM, Abhishek Kandoi wrote:
On Sat, Apr 20, 2013 at 11:34 PM, Rouslan Placella <rouslan@placella.com <mailto:rouslan@placella.com>> wrote:
On 04/20/2013 04:29 PM, Abhishek Kandoi wrote: > There was something I wanted to know about. > Would it be better to show an alert on the client side when an error > which can impact the client side system occurs? > Or as per my opinion we can simply create a custom modal box to show > only those errors which affect the client-side system badly in a simple > yet nice manner. Something like "Ops something went wrong, it may affect > your working. Want to send a detailed error report to the developers of > phpMyAdmin".
Dialogs for this feature should not be modal as, IMO, that would be too intrusive.
Got it, this would disrupt their working and may even make a bad impression of intrusion.
> This way we can get a detailed report from the user for really bad > errors. Hence helping our developers to better understand the possible > cause of the error, and hence better diagnose it. We can encourage > clients to send a bit descriptive error report which may contain what > all they did which resulted in a particular error. Tackling and fixing > bugs would become easier this way. > > Also I would request you to refine my idea so that I can set particular > goals for this project. Some more ideas from your side would be really > helpful.
Refining the idea is your job, not ours.
Sure, thanks for telling about this.
Oh, and we use bottom posting on this mailing list...
Sorry, but I didn't understand what you want to convey. I am doing it wrong? Please guide me if yes.
https://en.wikipedia.org/wiki/Posting_style#Bottom-posting
Ok, so here is what I have thought this far.
The client-side system would be behaving in the background without any disturbance to the client. The client-side system will send any Ajax Related error to our server-side system where the error will be stored in a database according to its type and the predicted level of problem that it can cause to the client-side system. Errors reported will contain no information about the client hence protecting their privacy. It would also be devoid of any kind of sensitive information which could possibly be hacked over a network hence removing the need for an encryption system.
At the server-side there would be a web-interface that will allow phpMyAdmin developers to diagnose errors related to Ajax. The system will provide all the information related to an error for the developers to look upon (I would be documenting both the client and server-side error system at the end of the GSoC). The documentation will also provide some information related to common errors that may occur on the client-side, thus helping them in the process of diagnosis.
The server-side web-interface would comprise of a simple left-side navigation menu for easy access to various locations on the website. The home screen would provide an overview of the recent errors that were added to the database and latest discussion by various developers on popular errors. Then there would be a functionality to directly forward bug reports to the phpMyAdmin bug tracker. Also as suggested on the ideas page there would be a functionality to search the database for specific types of errors based on their type, how frequently they occur. Moreover I was thinking of a small wiki for the error system so that a developer who has figured out the cause of a particular error can then document the problem to help others in fixing similar errors. This way other developers will be able to search the wiki for errors similar to one they are working on based on some tags(maybe), and hence fix them without loss of valuable time.
What do you think about it? Please comment.
Not sure we need the wiki, which is yet another system to maintain, as we have a bug tracker.
Bye, Rouslan
> On Tue, Apr 16, 2013 at 3:15 AM, Rouslan Placella <rouslan@placella.com <mailto:rouslan@placella.com> > <mailto:rouslan@placella.com <mailto:rouslan@placella.com>>> wrote: > > On 04/15/2013 07:16 PM, Abhishek Kandoi wrote: > > Hi Rouslan, > > > > Thanks for replying. I was unable to reply properly using my > SourceForge account. > I have worked with a few mailing lists like Google Groups, but this > one seemed different to me. > I didn't even get emails when you people replied on this thread > because I had my Digest Mode On, > thus I didn't have an option to Reply to All. > > > > I will be formatting manually for this time only, as I have no > email to reply to. > (Didn't wanna spoil the reply format) > > > > Rouslan Placella wrote: > > > >> Hi Abhishek, > >> > >> have you got a live demo of this application that I could try? > > > > Yes, you can try it online at > http://faceinbook.co.nr/flowork/home.html. > > Out of curiosity, was the app a college project? > > Also, I would like to hear from you about what you think are the > shortcomings of your implementation. Would you do anything differently > if you had to do it again from scratch? > > >> From your email, I'm getting the feeling that you didn't fully > >> understand where the different components of the system will > reside... > > > > Yeah, I got it a bit wrong on the first go. But on reading the > idea again I understood > what exactly it is about. > > > > > >> The server-side component of this system will not be for the users of > >> phpMyAdmin or administrators of individual phpMyAdmin > installations, it > >> will, instead, be used by the members of the phpMyAdmin development > >> team[0] to globally diagnose issues. > > > > I thought a client-side component for handling errors as well as > one for > diagnosing issues was suggested. But actually the suggestion was for a > client-side > component for sending errors to a server-side component with the data > containing > nothing that concerns the user about his/her privacy. Thus there is no > need of encryption > as you said, because the data contains no sensitive information. > > > > > > And also as you wrote that there is no means to check if a request > is valid, > and hence no need for checking for authentication. > > > > > > I would be happy to implement what you suggested about restricting > the number > of requests per IP to prevent the defacing of the server-system. Also I > will be > more than pleased to work on the server-side part to allow the > phpMyAdmin developers > to analyze and diagnose the errors. > > > > > > Also to prevent the back-end from attacks such as DoS you > suggested a global limit > on the number of requests. It seems easy to implement but will play an > important role > against DoS attacks. > > > > > > I will reply back after I work out a plan for the server-side > interface > and functioning for comments from you all. > > > > > > Rouslan Placella wrote: > > > >> The wiki is pretty comprehensive on the matter. Do you have a more > >> specific question? > > > > Yes, is there a place where I can upload a draft of my application > for my mentor to review it? If not, is posting it to the mailing > list fine? > > Not that I know of. You can post to the mailing list, but your draft > will be visible to other gsoc candidates. > > Bye, > Rouslan
Not sure we need the wiki, which is yet another system to maintain, as we have a bug tracker.
Ok. I did some research today and was trying to found out ways to create a system that can be easily extended in the future by other developers. I came across MVC as a good choice for the server-side system. This way we can separate the views from the models and create controllers to handle them. It would allow the future developers to easily extend the system. Also making the system a lot more organized. Also regarding the server-side system, a simple statistics page to visualize the data related to the errors is what I suggest. By simple I do not mean lacking on the information side. But rather having a simple user interface for a great UX for the developers. I don't want them to think what an element on the interface does. It should be obvious at the first glance. It is this simple that I mean. This would help the developers get an overview of the current state of the errors fixed and errors which require attention. I was thinking to use it to highlight the error which have affected a lot of client-side systems so as to get the developers attention. Moreover I would like the D3.js Javascript library for visualizing data as it would provide a good control over the visualization part. One of the graphs would help the developers in visualizing the number of errors added to the system per day. While one can help them visualize the ratio of the number of bugs fixed to the number of bugs reported in a day. These two are quite simple ones. I am working on some more useful and interactive graphs. Also regarding the bug fixing, can I fix any kind of bug or do I have to necessarily fix at-least one Ajax related bug? -- Abhishek Kandoi First Year, Computer Science and Engineering Indian Institute of Technology Roorkee About Me : about.me/kandoiabhi
participants (2)
-
Abhishek Kandoi -
Rouslan Placella