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

[Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>]

Hi Marcel,

Am 20.08.2011 14:49, schrieb Marcel Bruch:
> Doug Wightman contacted me yesterday. Their research group likes to move
> their code snippet search engine "CodeMatch"
> (http://languageinterfaces.com/) over to Eclipse. Mike Milinkovich
> suggested Doug that Code Recommenders may be a good place for this. 

+1

> 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/