Re: [recommenders-dev] [snipmatch] templates store

[Doug Wightman <douglasw@xxxxxxxxx>]

I think we should keep it simple, at least for now, and use
technologies that are tested and familiar :)

Cheng: you might find this interesting at some point:
http://snipmatch.com/APIExamples/SearchTest.html - it's an easy way to
test how the server currently responds to requests from the client.



On Wed, Feb 22, 2012 at 9:31 AM, Chen Cheng <chengchendoc@xxxxxxxxx> wrote:
> Yeah, i know what you mean, your TemplateStore class is what i am thinking
> :-)
>
> About the current directory structure, it is simple:
> + Main Directory
>    - Common Directory
>    - Anonymous Directory
>    - User 1 Directory
>    - User 2 Directory
>    .....
>    - User N Directory
>
>
> About CDO solution, it is cool. Another solution for SnipMatch to sync
> snippets store for client side and server side. If we use CDO store, we must
> give up JSON format and return back to EMF, not a big deal.
>
> 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.
>
> Let's wait for Doug's idea?
>
>
> 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
>>>
>>>
>>> Thanks,
>>> Marcel
>>>
>>> --
>>> Eclipse Code Recommenders:
>>>  w www.eclipse.org/recommenders
>>>  tw www.twitter.com/marcelbruch
>>>  g+ www.gplus.to/marcelbruch
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> --
>> Eclipse Code Recommenders:
>>  w www.eclipse.org/recommenders
>>  tw www.twitter.com/marcelbruch
>>  g+ www.gplus.to/marcelbruch
>>
>>
>> _______________________________________________
>> 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
>