On 10/02/12 16:14, Lionel Dricot wrote:
Hi,
Hi,
After discussing with Taras during FOSDEM, I've put some thoughts on how
to make DXR rock and have some appeal in the community.
Currently, I see some weaknesses that may hurt DXR massive adoption.
IMHO, this should be fixed before speaking more about DXR.
1) Indexing consume too much memory, making it impossible to use on less
than high-end server.
2) DXR is too tight to mozilla-central
3) Indexing is currently too slow (is it really a problem?)
4) DXR is hard to install and to use.
5) I still don't have a clear picture on how to use one DXR instance with
multiple repositories
Just some ideas I've been thinking of:
* Perhaps choose on one license for the project, currently 4 or so are
used.
* Do frequent releases and have versions. Right now there is no version
for DXR AFAICS.
* Have an easy method to automate indexing projects from the website
for people to try locally and/or on dxr.{lanedo|mozilla}.com. This
may be tricky for projects which have tough build requirements.
* One "dxr" command, this replaces "dxr-index".
* Clean up of the dxr code base, there seems to be a lot of png files
imported from some theme which we don't need. That would help with
deployment and packaging.
* Atomic update support in config/dxr command.
* The "dxr" command covers:
* entering a shell i.e.
dxr --shell
* creating a config (XDG locations, ~/.config/dxr/$profile.config) i.e.
dxr --create-config "foo" $2 $3 ...
* testing a setup is working by profile (e.g. do a HTTP request) i.e.
dxr --test
* add web infrastructure to web server location (in config file) i.e.
dxr --deploy
* add or update index i.e.
dxr --update or dxr --index
* Documentation via a man page for all this so people know how to use
it properly!
* Update the theme/look and feel. The usability could use some love too.
* Refactoring tool?
* Committers/Authors tool? Way to find out which businesses and who
from them is working on the code base. This would help people find
companies that could be offering services around those projects.
* Language limitations (support Java with gcj?)
* No property support (for languages like C#, etc), other languagisms
* Reduce memory footprint required (goal: index LO with dxr)
* Improve indexing time needed
* Provide more statistics about projects perhaps
* Perhaps some status information about the indexing progress for larger
deployments?
--
We should put these on the roadmap.
--
Regards,
Martyn
Founder and CEO of Lanedo GmbH.
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
