I have renamed the conversation, as I have decided to look at another project that has drawn my attention, which is COMDEV-108 (Adding Apache Solr to Bloodhound).
COMDEV-109 would have been interesting, but I’m not sure I would be able to create a thorough proposal by Friday (one that would cover all the issues that might arise when implementing a feature to make BH deployment easier). When searching information about Solr, I came across this[1] Python client for Solr which I think would be very useful to this project. Basically it creates a Solr instance, it indexes the documents provided, and then has methods that can be used for retrieving those documents. So the project would have the following requirements: * adding Solrpy to Bloodhound * adding callbacks to searchable objects in Bloodhound, so that they are indexed in Apache Solr * delegating searching to Solr (whenever someone does a search request, return the results provided by Solr, rather than the results provided by Woosh) In my opinion, using Solrpy would be better than building the feature upon the FullTextSearchPlugin[2], as it is an open-source library with thorough documentation. Do you think that my approach is suitable for this project? Thanks, Antonia [1] https://code.google.com/p/solrpy/ [2] http://trac-hacks.org/wiki/FullTextSearchPlugin On 17 March 2014 at 09:45:15, Ryan Ollos ([email protected]) wrote: On Sun, Mar 16, 2014 at 6:31 PM, Antonia Horincar < [email protected]> wrote: > In this case, what should be the scope of the project then? Should I stick > on having remote attachments on Amazon S3 and Google Drive (or etc), or > should I look further into making deployment easier? > I have doubts about the suitability of the remote attachments project reflected in the ongoing discussion about whether this can be accomplished without code changes, as well whether remote attachment storage is widely useful itself. We can certainly come up with projects that are useful in a limited scope, but I have doubts as to whether this is of high priority for Bloodhound. Making deployment easier is certainly a very high priority for the Bloodhound project. If you are able to define a project around that yourself, then I would say to go for it. However, I can't really give you much guidance as to what are good approaches without doing some research myself, and I don't think I will have time to offer much feedback or guidance within the time frame of the submission. I would like to think that deployment to Google App Engine is possible, but I don't know anything about the platform, so you'll really be on your own to research that. Certainly feel free though to send us the ideas you have, along with any good documentation references and maybe we can offer some guidance. So depending on how you are feeling about the projects at this state, that potentially leaves you with not much to build on, and we certainly want you to have a good project to run with since we've already seen that you are very capable and follow-through on the project. It's getting a bit late to switch directions unfortunately, but we have a pretty good list of projects in the i.a.o issue tracker (1). If one of those is a good fit with your interests, we can work with you to narrow the scope and define the project over the next several days. What Gary mentioned earlier about "remote access to subversion repositories" is probably a good project. There is the long standing ticket #493 (2) in Trac, and the issue of not supporting remote Subversion repositories comes up fairly regularly on the trac-users mailing list (3). There is also the pubsub integration (4). I can't tell you off-hand which approach to take, but the scope is narrow enough that I could see finding time in the next few days to offer guidance. Anyway, I wanted to make sure you knew that even though we are short on time, there is no shortage of projects! Btw, you had asked about config.py. The code in there is not easy to understand, which is a fact that I'm well aware of after trying to fix some config.py defects in Trac over the past week. Essentially though, config.py is a wrapper for ConfigParser (5). The classes in config.py need to be documented better! (1) https://issues.apache.org/bloodhound/query?status=!closed&keywords=~gsoc (2) http://trac.edgewall.org/ticket/493 (3) https://groups.google.com/d/msg/trac-users/X-d7dZkv-QI/OmfH6ad5R14J (4) https://issues.apache.org/bloodhound/ticket/478 (5) http://docs.python.org/2.7/library/configparser.html
