Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] server-side storage - Was: Call for Error Reports


2012/3/7 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>

On 07.03.2012, at 12:41, Chen Cheng wrote:

So, it means that we will move all the SnipMatch's server side logic to Eclipse.org ? Both snippets store and remote side search engine ? 

In the git-based approach no server-side is needed. Just a list of git repositories that are cloned und updated from time to time. Search takes place locally only.

Got it
 

This should be SnipMatch's official & default remote side server, in fact, users can set up their own custom remote server side in SnipMatch's Eclipse preference page.

In fact, that's would be the perfect solution we should strive for as part of the GSOC. Flexibility of storage solutions (which may also include the existing Snipmatch server side) is the ultimate goal. I think, the important thing is that there is a simple, network-efficient version that is hosted at Eclipse.org. Special (maybe superior) solutions may be added over time and for special scenarios and different environments.

I see the "git-approach + local search" as the default implementation. Not sure you saw that like this - do we have the same understanding of what happens on the server-side?

Yeah, in our past discussion, "git-approach + local search" is the default implementation, but there is another "remote search directly" work mode, in this scenario, user can get search result from remote server directly by http service.

User can switch in these two mode freely.
 

Thanks,
Marcel


2012/3/7 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>

On 07.03.2012, at 09:12, Chen Cheng wrote:

Local search version need also server side to synchronize and update snippets, so we should think about this point, where should we host the GIT based server side snippets store.

Just a few notes on this.

Eclipse Foundation takes uploading data very serious. We are currently in discussion with the Eclipse legal team and Technology PMC under which terms others can contribute snippets or models or data to the Recommenders project. I'll request a server at eclipse.org which will host the recommendation models and probably the git repositories. For the git repositories we need some kind of access restriction (e.g., a bugzilla account) to prevent spam - or maybe using Gerrit to take care of IP could work as well? Your thoughts on this are very welcome. It's an indirection but it may be good enough to convince Wayne? Wayne, are you listening? 


FWIW,
I'm working on a maven repository for recommendation models that can be easily consumed with Aether/Maven. In essence, the repository stores zip files containing the models in a maven-like coordinate system. These zip files are downloaded on request and used by recommendation engines running in Eclipse. I've implemented a prototype for delivering call completion models and plan to extend this approach to support overrides completion, and extdoc models as well. From what I can say at them moment it looks quite good and should scale well for Juno since models are served by Apache HTTPD only.

The API looks as follows: 

package org.eclipse.recommenders.rcp.repo;

@Singleton
public interface IModelRepository {

    // download from remote repos and install into local repo
     void resolve(Artifact artifact, IProgressMonitor monitor)

    

    // install own local artifacts into local repo
     void install(Artifact artifact, Artifact pom)

    // upload local artifacts to remote repo
     void deploy(Artifact artifact, Artifact pom, IProgressMonitor monitor)

    // get the file handle on this artifact to consume it in your recommender 
     File location(Artifact artifact) 

    // checks for updates of the given local artifact
     boolean isLatest(Artifact artifact) 

    // deletes the cached artifact from local repo 
     void delete(Artifact artifact)

    // simple querys: specify an artifact + version range and ...
     Optional<Artifact> findHighestVersion(Artifact query)
     Optional<Artifact> findLowestVersion(Artifact query) 
}

http://www.eclipse.org/aether/ has a video that gives more information about Aether.



Thanks,
Marcel



_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev




--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

Thanks,
Marcel


_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev




--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]

Back to the top