15 Apr
2013
15 Apr
'13
3:16 p.m.
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?
15 Apr
15 Apr
6:45 p.m.
New subject: [Phpmyadmin-devel] GSoC Project - AJAX Error Reporting
On 04/15/2013 07:16 PM, Abhishek Kandoi wrote:
what exactly it is about.
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.
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:
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?
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
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
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:
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
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
16 Apr
16 Apr
6:37 p.m.
New subject: [Phpmyadmin-devel] GSoC Project - AJAX Error Reporting
On 4/16/13, Rouslan Placella <rouslan(a)placella.com> wrote:
what exactly it is about.
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.
Ok. Thanks for the information.
On 04/15/2013 07:16 PM, Abhishek Kandoi wrote:
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.
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:
Out of curiosity, was the app a college project?
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. 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 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
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:
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. 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
Bye,
Rouslan
19 Apr
19 Apr
4:25 a.m.
New subject: [Phpmyadmin-devel] GSoC Project - AJAX Error Reporting
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(a)gmail.com>wrote;wrote:
On 4/16/13, Rouslan Placella
<rouslan(a)placella.com> wrote:
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.
fine?
--
Abhishek Kandoi
First Year, Computer Science and Engineering
Indian Institute of Technology Roorkee
About Me : about.me/kandoiabhi
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
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:
for my mentor
to review it? If not, is posting it to the mailing list 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
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
20 Apr
20 Apr
12:29 p.m.
New subject: [Phpmyadmin-devel] GSoC Project - AJAX Error Reporting
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(a)placella.com>wrote;wrote:
On 04/15/2013 07:16 PM, Abhishek Kandoi wrote:
again I
understood
what exactly it is about.
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.
--
Abhishek Kandoi
First Year, Computer Science and Engineering
Indian Institute of Technology Roorkee
About Me : about.me/kandoiabhi
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:
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?
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 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
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:
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
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
3:04 p.m.
New subject: [Phpmyadmin-devel] GSoC Project - AJAX Error Reporting
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(a)placella.com
<mailto:rouslan@placella.com>> wrote:
On 04/15/2013 07:16 PM, Abhishek Kandoi wrote:
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.
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:
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?
Hi Abhishek,
have you got a live demo of this application that I could try?
Yes, you can try it online at > 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
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:
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 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
4:24 p.m.
New subject: [Phpmyadmin-devel] GSoC Project - AJAX Error Reporting
On Sat, Apr 20, 2013 at 11:34 PM, Rouslan Placella <rouslan(a)placella.com>wrote;wrote:
Sure, thanks for telling about this.
On 04/20/2013 04:29 PM, Abhishek Kandoi wrote:
Got it, this would disrupt their working and may even make a bad impression
of intrusion.
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...
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
development
one for
diagnosing issues was suggested. But actually the suggestion was for a
--
Abhishek Kandoi
First Year, Computer Science and Engineering
Indian Institute of Technology Roorkee
About Me : about.me/kandoiabhi
On Tue, Apr 16, 2013 at 3:15 AM, Rouslan Placella
<rouslan(a)placella.com
<mailto:rouslan@placella.com>> wrote:
On 04/15/2013 07:16 PM, Abhishek Kandoi wrote:
differently
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:
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 Hi Abhishek,
have you got a live demo of this application that I could try?
Yes, you can try it online at if you had to do it again from scratch?
users
of
> 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 >
phpMyAdmin or administrators of individual phpMyAdmin
installations, it
>> will, instead, be used by the members of the phpMyAdmin team[0] to globally diagnose issues.
I thought a client-side component for handling errors as well as 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.
Also I
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. will be
more than pleased to work on the server-side part to allow the
phpMyAdmin developers
to analyze and diagnose the errors.
an
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 important role
against DoS attacks.
------------------------------------------------------------------------------
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
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:
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 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
4:32 p.m.
New subject: [Phpmyadmin-devel] GSoC Project - AJAX Error Reporting
On 04/20/2013 08:24 PM, Abhishek Kandoi wrote:
On Sat, Apr 20, 2013 at 11:34 PM, Rouslan Placella <rouslan(a)placella.com
<mailto:rouslan@placella.com>> wrote:
On 04/20/2013 04:29 PM, Abhishek Kandoi wrote:
https://en.wikipedia.org/wiki/Posting_style#Bottom-posting
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.
Not sure we need the wiki, which is yet another system to maintain, as
we have a bug tracker.
Bye,
Rouslan
development
one for
diagnosing issues was suggested. But actually the suggestion was for a
On Tue, Apr 16, 2013 at 3:15 AM, Rouslan Placella
<rouslan(a)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:
but this
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, 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.
differently
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:
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 Hi Abhishek,
have you got a live demo of this application that I could try?
Yes, you can try it online at if you had to do it again from scratch?
the
users of
> 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 >
phpMyAdmin or administrators of individual phpMyAdmin
installations, it
>> will, instead, be used by the members of the phpMyAdmin team[0] to globally diagnose issues.
I thought a client-side component for handling errors as well as 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.
play an
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 important role
against DoS attacks.
a
more
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 >> 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
21 Apr
21 Apr
3:03 p.m.
New subject: [Phpmyadmin-devel] GSoC Project - AJAX Error Reporting
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
4157
days inactive
4163
days old
8 comments
2 participants
participants (2)
-
Abhishek Kandoi -
Rouslan Placella