On Sat, Feb 18, 2012 at 9:44 PM, chen cheng <
chengchendoc@xxxxxxxxx> wrote:
> Hi Doug,
>
> Finally, see your words here :-D You guys did a really gread job, i am just
> standing on the shoulders of giants, HAHA
>
> Discussed with Marcel before, I have downloded and read SnipMatch's client
> code carefully. Regarding server side, I am familiar with Java relative
> solution personally, not know PHP much, so, i do not involve deeply in
> server side code, Fortunately, Doug will cover server side, so i can focus
> on SnipMatch's client merge and important job.
>
> Following is my personal idea and advises, we can discuss together, if there
> is something wrong in my opinion, please point out :-)
>
> Now, SnipMatch works like this:
>
> User input search label (such as "print" strings), SnipMatch client post
> this query string to server side. Search engine in server side will get the
> search result (such as "System.out.println()") and response to client side,
> i do not know search engine's detail, but very sure, we will keep improving
> it in the future. Client side get the response result list, user get one of
> them, replace the parameters, then insert into current editor.
>
> This solution works well, and we call it "Directly Search" solution, but i
> think there are still some problems in it:
> 1. No internet service, no SnipMatch, user can not use SnipMatch at all
> without internet. In some bad internet service area, such as China, this
> solution will affect many people. Or just consider this situation, if some
> group are developing hardly for a secret project, for security, they aren't
> connected with internet, but they want to use SnipMatch, what can they do ?
> 2. Search query will grow rapidly when SnipMatch users grow, we have
> to invest more and more money about server side hardware in the future.
>
> So i am thinking supply another SnipMatch's client solution, call it "Local
> Search". User can choose his favorite way between "Directly Search" and
> "Local Search".
>
> Local Search solution works like this.
> 1. User store Snip Code Templates in local cache & storage, there are three
> kind of code template:
>
> I. Public common templates which keep synchronous with templates in remote
> SnipMatch's server.There is a thread keep the synchronous
> things over a period of time when internet service is free.
> II. Personal templates which also keep synchronous with his own template
> base in remote SnipMatch's server
> (Use SnipMatch account as store ID in SnipMatch's server database).
> User can decide whether share these templates with local anonymous users or
> other login users have SnipMatch
> account, perform this in SnipMatch's Eclipse preferences.
> III. Anonymous local templates, each user (No matter login or not) can use
> these templates.
>
> 2. We store templates in local storage, so we have to supply a local
> template search engine. At the beginning, may be
> just a string compare crude engine, but we will improve it as a Lucence
> based powerful one in the future. May be we can
> consider reuse Recommenders' other search engine.
>
> 3. Just like Apache Maven, user can set up third part Code Template
> repository besides SnipMatch's official
> side(current
http://languageinterfaces.com/) .
> Build the server side service by using SnipMatch's server side solution,
> then add/remove remote address in SnipMatch's Eclipse preferences.
>
> Besides Jakob's snippet editor job, and advanced local search engine, i can
> handler all the other jobs. If there is no proper guys can support local
> search engine. I can just build a simple one, design proper interfaces, then
> cover this after all the other basic jobs done.
>
> Here is my initial plan, your advises? Time is not much if we want to catch
> Eclipse's release, may be i should start development job before GSoC start
> in April.
>
>
>
> 2012/2/19 Doug Wightman <
douglasw@xxxxxxxxx>
>>
>> Hi Cheng!
>>
>> Yes, please go ahead and merge SnipMatch into recommenders. Sorry for
>> the delay - I've been stuck organizing a conference (
tei-conf.org)
>> that's starting tomorrow. I think this would be an awesome GSOC
>> project and would be happy to support any way that I can.
>>
>> Great to have you on board, happy to answer any questions you have!
>>
>> Doug
>>
>>
>> On Fri, Feb 17, 2012 at 9:22 PM, chen cheng <
chengchendoc@xxxxxxxxx>
>> wrote:
>> > Ok, i will read the SnipMatch's source code first.
>> >
>> > One question: Does SnipMatch and Recommenders' merge job start yet or
>> > not ?
>> > In my view, it is not hard if we just merge SnipMatch's source code into
>> > Recommenders. Do we have a full plan about how to improve SnipMatch's
>> > current features ? Or we just start this part of job from zero.
>> >
>> > 2012/2/18 Marcel Bruch <
bruch@xxxxxxxxxxxxxxxxxx>
>> >>
>> >> Hi Cheng,
>> >>
>> >> I was hoping Doug would jump in and provide more details on Snipmatch.
>> >> Maybe he's off for a few days.
>> >>
>> >> Your summary is right to the point. That's how the system works. Doug
>> >> has
>> >> committed the sources to our Eclipselabs repositories. You might spent
>> >> some
>> >> time on the sources and dive into the internals
>> >>
>> >> here
http://code.google.com/a/eclipselabs.org/p/code-recommenders/source/browse/?repo=kiyomi
>> >>
>> >> Let's wait a few days and get Doug and/or Zi involved...
>> >>
>> >> Best,
>> >> 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
>
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev