On 22.02.2012, at 15:31, Chen Cheng wrote: All roads lead to Rome. It depends on which way we choose. Our current solution seems more simple, but if you prefer EMF + CDO, i am OK too. At least, in SnipMath client side, there is no big difference.
Maybe I was too enthusiastic with CDO :) I meant "let's stick with JAX/RS + JSON + GIT" for the GSOC and first prototype but keep the doors wide open for other implementations.
If Sascha want's to give CDO a try I'd be happy to see a CDO based implementation (because I think (!) it has some nice features in terms of interactivity and may be suited for in-house). But I'd favor the GIT+JSON approach as primary crowd-sourced implementation for Snipmatch.
Let's wait for Doug's idea?
Timezones are a pretty challenging thing :) We didn't change anything so far. Thus, I'd continue as you and Doug had planned before.
2012/2/22 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
If have one "composite store" composed with many "simple store" (your class has implemented already). The whole search method of SnipMatch will be like this:
1. Invoke composite store's search method 2. composite store's search method invoke all the simple stores' search method 3. merge all the search results and then get a List<MatchNode>, return
It is some kind of troublesome. Is it? I don't think it's a problem but anyways. I think "let's go!" and "document the structure". We'll probably see soon if the currently planned structure works out well enough or not. I still like the idea of having a CDO store for in-house repositories. If it's encapsulated well, we won't get any trouble when exchanging the internal implementation. So no worries on my end.
Regarding indexing: The implementation I've proposed is just a sketch. Nothing is set in stone in this class. Going into subdirectories for indexing etc. will be implemented as soon as you have decided on the layout. I'll take care that the indexer works as you expect it to work.
Hope this answered all your questions (not exactly sure this time)
On 22.02.2012, at 14:08, Chen Cheng wrote:
If have one "composite store" composed with many "simple store" (your class has implemented already). The whole search method of SnipMatch will be like this:
1. Invoke composite store's search method
2. composite store's search method invoke all the simple stores' search method 3. merge all the search results and then get a List<MatchNode>, return
It is some kind of troublesome.
In fact, we should only notice that TemplateStore's snippetsdir means snippets' main directory, there are also some sub directories in it. When you create and update Lucene's index, do not forget this point, it is enough. Isn't it ?
This method:
private void updateIndex() { for (final File f : snippetsdir.listFiles()) { // iterate all snippetsdir's subdirectories here to get all the files
} }
You idea ? 2012/2/22 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
I like your proposal to use a list of folders and and having different ones for different use cases! How about having one "composite store" that in itself be composed of many different stores (and store implementations)? One such implementation (or instance) would be "private", one "shared", one "community" etc.
The code I've submitted would than just handle one snippet repository but many of them. Anyway, you decide on the implementation and I'll fully support your decision on this.
Best, Marcel
On 22.02.2012, at 13:39, Chen Cheng wrote: Hi Marcel,
May be i should read your code first, then i will not post last mail :-)
Yeah, your code is what i think, just a small detail, i think there should at least 3 sub-directories under snippets main directory. They should be:
1. common: store snippets sync with remote server, check out only, can not check it. 2. personal snippets directory, named by userid may be, store personal snippets sync with remote server, *owner* can check out and check it. So if there are several different users, there may be different personal snippets directory.
3. anonymous: store snippets used only in local, edit without id identify certification, will not sync with remote server. 2012/2/22 Marcel Bruch <marcel.bruch@xxxxxxxxx>
Hi Cheng,
did you already create a (preliminary) API for the template store? I think, all details will be hidden behind some interface (maybe configurable by extension points and preferences in Eclipse later on). This probably also includes storage, searching, caching etc.
To write the indexer I need to see some kind of interface to integrate with. I just had 90 minutes spare time (exam supervision) and scratched a few bits to start the discussion. See this class for what I had in mind at the beginning: http://goo.gl/vXjZc Please note, that this is a skeleton only and not considered to work ATM. Just looking - no execution :)
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
|
