[Teammetrics-discuss] GsoC Project Weekly Report 1

[Vipin Nair]

Hi Andreas,

> I can confirm that finally people would be keen on "lynx-enabled" pages
> - so yes despite all beauty of JS-features we also should gain for
> simplicity.  I would care more for some control logic like:

Can avoid JS, but I am not sure what else needs to be done to make it
"lynx-enabled". Ascii art representation of graphs on detecting
terminal based browsers should be fun thing to do! :) I'll definitely
look into this later.


>  1. How to reasonable select 1 team
>  2. How to reasonable select X teams for comparative display
>  3. What measures (mailing list activity, commits, closed bugs, uploads)
>    should be displayed in 1. and 2.)
>  4. Selecting a certain time span for 1. and 2.
>  5. How can I ask for a team not yet in the statistics
>  6. ...

If we are dynamically rendering the graphs on client side, all these
can be done in an awesome way. If we a rendering these graphs on
server side and an image is sent to client side, there cannot be any
sort of interaction. For example, If I need to add an additional
metric to an existing graph, Instead of any page reloads, I can redraw
the graph on the immediately (fetching data from the server
asynchronously) which is very fast.

> Getting a really *usable* interface for interaction (even with lynx/w3m)
> in the first place would be cool and for sure it does not harm if it
> looks nice in graphics enabled browsers.  I do not really claim that the
> existing graphs produced using GNU R are nice but these work for the
> moment.  Depending on how far we might stretch the feature selection we
> will be able to decide whether we need dynamically created graphs or
> whether a set of static graphs (in whatever way they might be created
> finally) will do as well.  If we for instance consider it a good idea to
> display a selectable set of teams in a selectable time frame static
> graphs are out and we need some dynamic rendering (I have not yet made
> up my mind whether this should be done on server or client side - no
> strong feeling about this).


If we are rendering the graphs on the server side, instead of doing it
on demand, it is always better to pre render all the images and just
send it to the browser when it is requested. But having the graphs pre
rendered limits what a user can do. Say, if we decide to render a
particular metric of team for a time span five years, this is fixed
and the user cannot select the time range, in that way the interface
becomes less usable.

On the other hand if we are rendering the images on demand, even with
basic caching, this would be resource intensive and it will slow down
the website. Having a fast website is good.

The best and the cheapest option in terms of server resource
utilization will be to present data, as is, say in some tabular form
without any sort of visualization (graphs rendered as images) for non
javascript environments (works with both javascript disabled browsers
and terminal browsers) and client side rendering for javascript
enabled environments.

The advantages of this approach are:

1) Fast

All we send from the server is text data so it is very fast. For
example, in the prototype I wrote to support my GSoC application, I
have provided a static and dynamic example.

    [1] Static example : http://debmetrics.appspot.com/teammetrics/commitlines/
    [2] Dynamic example :
http://debmetrics.appspot.com/dynamic/teammetrics/commitlines/

If you would have noticed, the dynamic example renders *much* faster
than loading the image from blends.d.n. In the dynamic example, I am
generating an image by calling an API that generates JSON data on the
Google server by parsing a text file on blends.d.n server, in actual
practice, this will be much faster because I generate the JSON from
the database in the same server and all the communication overheads
are removed.

2) Efficient

Since we are only sending text data, it is very bandwidth efficient.
If we do not render any visualizations on the server, it would be
consume very less server resources.

Please to do tell what you think of this idea.

> Following Enrico has proven to be a reasonable thing to do. :-)

I'll do this soon :)


-- 
Regards,
Vipin Nair
National Institute of Technology, Calicut
http://swvist.github.com