On 11 March 2014 at 15:40:24, Ryan Ollos ([email protected]) wrote: On Mon, Mar 10, 2014 at 7:07 PM, Antonia Horincar < [email protected]> wrote:
> Hi devs, > > First of all, I would like to say that I am very glad that the project I > worked on last summer is going to be part of the next release of > Bloodhound. Thank you for your help, I learned a lot during that time and > even though atm I feel I could have done a better work, it helped me learn > many new and useful things (I even applied some of the things I learned on > my dissertation project). > > I am planning on applying for GSoC 2014, and have researched some of the > proposed projects. So far, the project I'm interested the most is > COMDEV-109 [1]. > > I would like to ask whether you would prefer a particular storage service > to be used for Bloodhound, or you would prefer users to have the > possibility to chose from a number of services when storing their resources? > > I have looked at two SDKs for filesystem abstraction: Boto [2][3] (which > contains an API for managing files on an Amazon S3 instance), and Google > Drive SDK [4] (part of the Google API [5]). The Google Drive API also has > an implementation of a Python wrapper library (PyDrive [6]), which might be > useful for this project. > > The questions I have so far, regarding COMDEV-109, are: > Where can I find the modules that deal with file uploading/storing at the > moment? > Is there any existing integration between Bloodhound and Google App > Engine, as it would make Google Drive integration easier? > > I am looking forward to finding out more about this project. > > Thanks, > Antonia > Hi Antonia, It is great to have you back, and congratulations on your successful project last summer! The new GSoC students will certainly benefit from your words of wisdom on how to have a successful project ;) I've not given the COMDEV-109 project a lot thought, so others might have better feedback. It seems to me that you'll might want to consider where to store everything in the environment directory, including the SQLite db file for the case of running SQLite (although perhaps the project could be limited to PostgreSQL and MySQL installations). I’m not sure I understand correctly what you mean by that. Do you mean that all the files in the environment directory would also be stored on a cloud service, and not just attachments added by users? Focusing on file attachment storage might be a good way to limit the scope though. I assume you'll need to add an API to Trac for integrating with external services, as well as integrating with at least one service. Studying and considering several services might help with determining how to make a suitable API, which appears to be what you are already doing. I imagine there will be some significant changes to the Trac code, which we can then push upstream to the Trac project (you can leave that part to us for the sake of keeping your project of reasonable scope, and we'll make sure you are credited as the author of the changes submitted to Trac). I've seen discussions mentions of using Trac on Heroku and Google App engine, but I'm not sure anyone has deployed it to those targets: http://trac.edgewall.org/ticket/11339 http://trac.edgewall.org/ticket/10433 To answer your specific questions, Where can I find the modules that deal with file uploading/storing at the > moment? You'll want to look at the trac/attachment.py module. If you consider the configuration data to be in the scope of your project, then you may also want to look at trac/config.py. Is there any existing integration between Bloodhound and Google App Engine, > as it would make Google Drive integration easier? None that I know of. It wouldn't hurt to ask on trac-users or trac-dev mailing lists as well, after scouring StackOverflow and similar forums to see if anyone has done something similar. http://trac.edgewall.org/wiki/MailingList It seems to me that this is a very useful project, which could significantly lower the barrier to deploying Bloodhound. A large percentage of the activity on the Bloodhound and Trac users mailing lists is due to users having trouble with installation steps, including web server configuration. If we could deploy to Google App engine in a minimal number of steps, we might capture a much larger user base - those that might not otherwise be willing to fight through the installation steps - as well as saving ourselves time supporting users with installation issues. Bitnami Trac has lowered the barrier for Windows users, but I haven't seen an equivalent for Linux. I'm not sure it is in the scope of your project, but creating a simple deployment to, for instance Google App engine, would be a great project. There was another student that expressed interest in the COMDEV-109 project after you, so maybe we can have multiple projects that converge to that end goal. How challenging do you think implementing the deployment to Google App engine would be? I am trying to find out as much as I can about both directions the project could go (deploying BH to Google App Engine, and creating an API to store attachments on external services). I would definitely like to implement a feature that would allow deployment to be made more easily (and on a cloud hosting service), as it would help BH’s users, but I can’t estimate how difficult would the challenge be. Also, I looked over the trac/config.py file, however it’s very difficult to understand what each code part deals with (at least for now, I’ll probably get to understand more once I spend some more time analysing it). I couldn’t find documentation for the classes in trac/config.py and how they are used for deployment, do you know more about it? I am looking forward to your reply. Thanks, Antonia - Ryan
