On
21.08.2011, at 08:57, Gunnar Wagenknecht wrote:
> 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/
