Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of visual.logic@gmail.com
 designates 209.85.212.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=J/me32ZPuG15Xwww4gmnfuO4vJB7Cc+7ML9soUWQVK4oVWbWzEwhMbnpsrLZIGdzxe
         oay6ovlTogcuwzJ6wJKw7RxmEe5MFysqaKnyIe0Il7Bs1vjL8pe5atAP00cffJYotM+U
         oLDMoVTdWuiwU6whBvi5GRq1gFUBL9+4m7C/M=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1078)
Subject: Re: Using JSON for index input and search output
From: Visual Logic <visual.logic@gmail.com>
In-Reply-To: <AANLkTinhPHPPBOIRj2H5CL6UctJz8WSDAeSorJfsJ38r@mail.gmail.com>
Date: Sun, 30 May 2010 15:11:17 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8815C552-9B8A-4963-AD59-8AB4553A17AB@gmail.com>
References: <CE9C01A4-45FA-437A-A083-9F4D049F586E@gmail.com>
 <AANLkTimQpWxIM7H2prKlxpLAfKng4XRaBoRbpMGEBFfW@mail.gmail.com>
 <02C687A6-A1FB-4C82-B173-034133BFBE48@gmail.com>
 <AANLkTinhPHPPBOIRj2H5CL6UctJz8WSDAeSorJfsJ38r@mail.gmail.com>
To: java-user@lucene.apache.org

This is interesting.

I'm coming into this with only the knowledge I gained from the 1st =
version of the Lucene in Action book, which I read a few years ago. So =
when I think of embedded I think that Solr would be integrated into my =
app like any API would be. Instead you say Solr is a separate process =
that could work adjunct to my app. In other words in my mind it would be =
a extension module or even plugin for my app. Would be possible to =
start/stop it from my app as well? Hope I'm seeing the picture clearly =
now?

What I find most useful in Lucene is its searching capability. Since I =
have pre-structured data which are the different configurations the =
different tools and tiers of my app use the analysis stage is not that =
involved. Once data is indexed, likely in several indexes/cores, I would =
like to search for specific documents and set them to be the current =
context for different tools. There are a number different contexts and =
index documents specific to each of them. I guess what I am after is a =
searchable configuration engine for a RIA.

Some of my use cases can tolerate a bit of latency but for others it =
would not work so well. Here are two of the more dynamic use cases =
(slightly simplified to make them clear) where searching has to be =
blazingly fast:

1 - I have a draw tool that places different shape types while dragging =
(each drag forms a string of shapes) across a canvas. I track the types =
of shapes the current drag has placed so far and then what to recommend =
other shape strings (prior drawn strings are indexed as they were made) =
that are similar in order to help the user complete the current draw =
string. The query would be created on the fly based on what shapes have =
been drawn so far and then used to search the index, the search would =
also need to be refreshed every time the user moves the mouse. This use =
case is similar to type-ahead phrase completion but completely mouse =
driven with fired searches in the background and immediate graphics on =
the canvas. Will Solr running as a separate local process be able to =
keep up with the user driven drawing?

2 - My app features a Painter with Renderers for different shapes. The =
many possible layout and style details for these shapes and their =
relation to each other are defined as configurations per Renderer. The =
index would contain multiple versions of a configuration for a given =
Renderer. A search would then be used to bring up a set of =
configurations, the set would have a configuration for each Renderer. =
This set would then be the active rules (context) for rendering each =
type of shape. Then as the user creates shapes by drawing different =
shape types they are rendered by their specific Renderer. The given =
Renderer in turn looks up all the rules for layout and styling it should =
have from the active set of configurations. The question is if the =
lookup can be on the fly searches to a index or if it is better to pull =
up the set of configurations from the index and transfer them to =
hashmaps that the Renderers would query instead of querying the index =
directly? Would Solr be able to keep up with all the real-time lookups =
the Renders would be making?

VL


On 2010-05-30, at 1:38 PM, Yonik Seeley wrote:

> On Sun, May 30, 2010 at 2:27 PM, Visual Logic <visual.logic@gmail.com> =
wrote:
>> Solr is embeddable but does that not just mean that SolrJ only =
provides the ability to call Solr running on some server?
>=20
> Nope - embeddable as in running in the same JVM as your application.
>=20
>> For some of my use cases using Solr on a remote server would work =
fine. For other cases it will not be quick enough,
>=20
> Running as a separate server can be on the same host and be very
> quick.  Was it too slow when you tried it?
> It's a common misconception that HTTP is slow... it's really just a
> TCP socket (which can be reused with persistent connections) with some
> standardized headers.  Solr also has a binary protocol that works just
> fine over HTTP, so it's really not more overhead than doing something
> like talking to a database.
>=20
> But the right solution probably depends on the details of your
> specific usecases - if you elaborate on them, people may be able to
> provide more specific recommendations.
>=20
> -Yonik
> http://www.lucidimagination.com
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org