On Mon, Mar 10, 2014 at 9:07 PM, Antonia Horincar <
[email protected]> wrote:
> Hi devs,
>
>
Hi Antonia !
Welcome back
> 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).
>
You did a very good work last year , congrats !
>
> I am planning on applying for GSoC 2014, and have researched some of the
> proposed projects.
It's good to hear from you once again .
> So far, the project I'm interested the most is COMDEV-109 .
>
>
I recall I submitted the original ticket [1]_ once upon a time for GSoC
2013 ; so I'll try to explain what is it about . Hosting services sometimes
offer limited disk space . Attachments and other file cache (e.g. PlantUML
plugin) consume a big amount of available resources . Besides there is a
chance for attachment access patterns to be , write once read never .
Therefore migrating these onto a file hosting service is an approach that
could help with overall server performance .
> 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?
>
>
The targets I'd prefer to consider to deploy in blood-hound.net web site
are :
- Google Drive
- Sky Drive
so , yes , this means that should you decide moving forward with this
project then I'm keen to be providing you with feedback , reviews and
suggesting modifications based on performance measured on those servers .
> I have looked at two SDKs for filesystem abstraction: Boto (which
> contains an API for managing files on an Amazon S3 instance), and Google
> Drive SDK (part of the Google API ). The Google Drive API also has an
> implementation of a Python wrapper library (PyDrive [6]), which might be
> useful for this project.
>
The criteria I'd suggest to choose one of them are :
- Having a Python client library is very useful to speed up development
and focus
on the project.
- In order to include it in core licensing matters
- User interest
SkyDrive also has a well maintained Python client library [2]_ , but it is
distributed under the terms of WTFPL [3]_ [4]_ . License compatibility is
TBD .
OTOH Google most of the time distributes OSS client libs under the terms of
Apache v2 License . No problem with using that .
>
> 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?
>
e.g. trac/attachment.py , but also beware of the fact that plugins may be
interested in using these APIs as well .
> Is there any existing integration between Bloodhound and Google App
> Engine, as it would make Google Drive integration easier?
>
>
Considering my description above I do not think GAE will be a target for
this . AFAICT it's unlikely to run BH on GAE atm . At least the goal of the
original ticket did not consider running BH on the cloud as a pre-requisite
.
> I am looking forward to finding out more about this project.
>
I'm hoping this message will clarify a few aspects of the original idea .
> [...]
.. [1] https://issues.apache.org/bloodhound/ticket/486
.. [2] https://pypi.python.org/pypi/python-skydrive
.. [3] http://www.wtfpl.net/
.. [4] http://en.wikipedia.org/wiki/WTFPL
--
Regards,
Olemis - @olemislc
