Re: [technology-pmc] CodeMatch code snippet search engine considers movi

[Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>]

Hi Gunnar. This mail continues the discussion about service hosting and community/crowd-sourcing for Code Recommenders.


I tried to summarize your email. If I read it correctly you describe two solutions:

1. Hosting all servers at Eclipse Foundation
2. Create a public sharing API, add support for multiple knowledge-bases/connectors (such as community, in-house etc.). Then, server doesn't have to be hosted at Eclipse.

Regarding data privacy/sharing, you say that it's a matter of trust and we (Code Recommenders) have to be very careful which data we use. But everyone can decide to contribute or not, and thus, there is no severe problem.

Is this (*very* condensed) summary correct?



I'm not sure I got your last point:

> Of course, you should not enable a public connector with a bunch of packages listed per
> default.

What do you mean with "with a bunch of packages listed per default". Will there be any (public-or-not) connector be enabled per default?

Thanks a lot!
Marcel



On 21.08.2011, at 08:57, Gunnar Wagenknecht wrote:

> Hi Marcel,
> 
> Am 20.08.2011 14:49, schrieb Marcel Bruch:
>> 
> 
>> The overall question is:
>> 1. Can we offer these services as part of Eclipse(!) Code Recommenders
>> project?
>> - or -
>> should we skip vendor-neutrality and let every subproject use it's own
>> server and deliver its tools without any association to Eclipse?
> 
> I think you have two things to consider.
> 
> You can ask the web masters for your own virtual server. For example,
> the EGit project does that to run Gerrit. However, this consumes
> Foundation resources. Thus, *IMHO* I think at some point in time it
> would be nice to have some funding for it (eg. FoE sponsorship).
> 
> On the other hand, what you guys are doing is valuable not only to open
> source developers. Thus, you might consider developing the collection
> server and reporting engine as part of your project too. Companies
> should be able to download it and run it within their networks for
> closed-source projects.
> 
> Thus, you should allow people to configure multiple "connectors". IMHO
> it's also great if there are public usable 3rd party connectors. Because
> the protocol is developed within your project and EPL licensed everbody
> can review it and see what's transfered over the wire.
> 
> Of course, you should consider implementing some security and
> scalability features. Frankly, there is no value in encrypting data when
> transferring them to open, public services for public consumption by
> developers. However, within a corporate network it would make sense to
> encrypt the data. Additionally, encryption should be customizable per
> connector so that company A cannot decrypt data of company B without
> gaining access to their secret key (for example).
> 
> You should also be careful about what data is collected on a per
> connector base. For example, public connectors should never get usage
> data of closed-source code. Thus, an explicit white-list approach of
> selecting packages per connector sounds like a good option.
> 
> Regarding data privacy I see it also a matter of trust. If the connector
> owner says "hey I don't collect your IPs" than I have to trust them. If
> I don't that I simply won't use the service.
> 
> If the above points are met, I have no strong opinion about requiring
> the service to run within the Foundation infrastructure. Of course, you
> should not enable a public connector with a bunch of packages listed per
> default.
> 
> -Gunnar
> 
> -- 
> Gunnar Wagenknecht
> gunnar@xxxxxxxxxxxxxxx
> http://wagenknecht.org/



-- 
Eclipse Code Recommenders:
 w www.eclipse.org/recommenders
 tw www.twitter.com/marcelbruch
 g+ www.gplus.to/marcelbruch