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]
