Re: [silpa-discuss] Continue Working on Proposal

[Vasudev Kamath]

On Tue, Apr 22, 2014 at 2:43 PM, pravendra rathore <address@hidden> wrote:
>> but probably your dash board idea has convinced none of us, if you still
>> think its needed then convince us first!.
>
> Here I'm confused that you are talking about all three tools I proposed or
> only Dashboard one.
> anyway, I am trying again to convince you people.
>
> Proposal Project was divided in 2 parts :
>
> 1. REST API Development
> 2. Tools Related to Project-SILPA
>
> I know first was clear to you as it was mentioned already there in ideas
> list.
> I proposed second part of project because I see/use related things daily
> here for my software group(SDSLabs) or on internet.

Ok some nitpicking here so that we can openly think on these points.

>
> it consisted 3 tools :-
>
> (a). Admin/Developer Control Panel
> Now lets see some problems or issues in daily life work, for example :
>
> - You are debugging an existing module(ex. Transliteration) and don't want
> production side API affected by your code changes. So a solution separating
> Development and Production API's is needed here.

Probably I can still do these running a dev.silpa.org.in and
silpa.org.in separately where development code can be tested on
dev.silpa.org.in and I will not cause problems to production code!. Am
I missing any scenario which you are trying to solve?

> - API service is working fine, suddenly you want to remove a particular
> module or add(or in simple way kind of enable/disable)

I can simply comment out the module in configuration and our services
are configured to reload the entire app on file touch and Wala it
works :). But probably a front end to config may be good idea!.

> - if we move ahead (as Project-SILPA is growing) and implement
> authentication based API then it can help Admin to stop service for a
> particular client, in case client is creating some issue (Security related
> feature)

Probably security thing is not the problem which we need to solve in
our framework isn't it?. there are tools like iptables or fail2ban
which can be enforced on misbehaving clients. Also we don't hold any
state and don't plan to do that in future also. Having no state our
application doesn't care who sends us requests then how do you plan to
solve this problem? (but I prefer external utilities to safe guard
from misbehaving clients).

>
> now, both 'Status Board' and 'Developer Dashboard' are basically same as a
> purpose, having difference only that some Statistics that you don't want to
> be publicized are in 'Developer Dashboard' additionally to 'Status Board'.
>
> some features that I proposed for them are :-
> - Status on API use
> - Relative Distribution of modules in API use
> - API Response Time
> - API Service Uptime

Can you explain  more on this status thingy? I'm unclear what you were
trying to solve here.

>
> an Additional feature in 'Developer Dashboard' as I said can be 'Tracking
> API use by clients' if we move ahead with authentication based API. now
> obviously we don't want it to be public as I defined.

Authentication will probably never be implemented in our case I guess.

>
>>
>> We were surprised to see this idea being proposed because we don't need
>> any such tools or dashboard.
>
> I proposed this all by seeing continuous Development under Project-SILPA as
> Android SDK related project got selected this year, so there will be android
> apps powered by SILPA and so on.
> may be, you will say one day on your own that we need this, if project carry
> on going under development.

May be my explanation above will give you picture on why we were
surprised! :). And if you have discussed it with us before probably we
could have converted it into much productive idea :). But anyway.

>
> and about 'Status/Dashboard'..
> yes, in my view, having an API status board is not a thing that you need
> necessarily as a Developer Role,
> but people using your API will need it for their applications they want to
> implement using your service.
>
> actually I liked the project, its use cases and have experience in API
> Development, so got more interested.. thats why still want to contribute.
> Hope this make things clear to you.

The REST api implementation is still open but you might need to look
for development branch before implementing it!. Also there aree tons
of refactoring needs to be done most of them are inside my brain only
which is bad, I'm trying to find some time to document it but if you
can join us I can share those information and you can see what you can
implement in those.

>
> PS : should I send it to address@hidden also .

Yes please send it to address@hidden, so others can also contribute.

Cheers,
-- 

Vasudev Kamath
http://copyninja.info
address@hidden|vasudev.homelinux.net}