[Toolserver-l] collaborative report generator?

Pietrodn powerpdn at gmail.com
Sat Sep 13 08:26:08 UTC 2008


That seems cool.
Are you going to write it in PHP?

One problem is the data visualisation. We can simply create a wiki  
(un)ordered list of links (with * or #).
We can define the format in the SELECT clause with a CONCAT  
instruction. I think we shouldn't give the output in CSV/XML, because  
the most frequent uses of lists are:
* Manual use from wiki users
* Automatic use with bot (which require a list of links, too)

I'm sorry I can't help with the writing of code, my PHP/CGI experience  
is very limited.

Regards

Il giorno 13/set/08, alle ore 08:58, River Tarnell ha scritto:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> so, it's quite common that people want various kinds of reports on  
> wikis, which
> are usually generated by a standard SQL query.  in fact, this is so  
> common that
> we have the "query service" to handle these requests.
>
> this isn't the most efficient way to do it, though; a toolserver  
> user has to
> run the actual query, and if it's meant to be a regular report, they  
> need to
> crontab it to run as needed.  there's a lot of duplication of effort.
>
> instead, what about a collaborative 'report' tool?  i would envisage  
> this
> working as follows: each query (for example, '100 users with most  
> edits') is
> described in a file.  the exact way isn't that important, but for  
> the sake of
> example, the file might look like this:
>
> name=Top 100 editors
> # For a slow query, run it once a day from crontab.  Faster queries  
> could be
> # done on demand (for example, 'when=immediately'), or cached for a  
> certain
> # period of time (for example, 'cache=1h').
> when=nightly
> query=SELECT ...
>
> then for users, there's a web interface where they can select the  
> wiki and the
> report they want to run.  for queries that need parameters (e.g.  
> those that
> report on a particular article), they could select the article  
> (preferably with
> a nice ajaxy input box).  then the SQL might look like:
>
> SELECT ... WHERE page_namespace=<NAMESPACE> AND page_title=<TITLE>
>
> <NAMESPACE> and <TITLE> would be filled in by the report generator.
>
> the web interface would display the result of the query in a nice,
> easy-to-read table (and probably with some kind of XML or CSV export  
> feature).
> any project developer would be able to add new queries, which users  
> could
> request in JIRA.
>
> as the project would have many developers, i envisage it running on  
> the stable
> server.  if people are actually interested in doing this, i'd be  
> willing to
> create at least the basic framework (hopefully the interface would  
> have several
> maintainers who would add nice features).
>
> opinions?
>
> 	- river.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (SunOS)
>
> iEYEARECAAYFAkjLZI0ACgkQIXd7fCuc5vIsjwCgtnOixZhmqE+SNzQ/vnliTdzF
> f7wAmwcdE6ctpH8//aMg79BcsUJuxQNp
> =Q0vB
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Toolserver-l mailing list
> Toolserver-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/toolserver-l

Pietrodn
powerpdn at gmail.com




More information about the Toolserver-l mailing list