Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE:  Re: Lucene and remote index and java applet,
 with no java app server
Date: Mon, 10 Oct 2005 13:46:42 -0700
Message-ID: <1A6B6A5A3597C340BB63728001DC787902331024@kodos.na.wrq.com>
Thread-Topic: Re: Lucene and remote index and java applet,
 with no java app server
thread-index: AcXN2MT11+A861I1TPOaL/sX/4SaHAAASqUA
From: "Jon Schuster" <jons@attachmatewrq.com>
To: <java-user@lucene.apache.org>

Sorry about that, "download" was a poor word choice.

By download, I meant that after the applet opens an input stream to the
URL, it will need to read from the stream to get all the index data from
the web server to the user's machine so the applet can perform the
search. Whether the index files are downloaded and written to disk or
whether they're downloaded and cached in memory, it's still a bandwidth
consideration. As you mentioned earlier, the index files could live on
the server as zipped files, and the applet could unzip them on the fly.

Signing the applet would make things somewhat easier. But then you have
the potential problem of users who have been trained by their IT
departments (or have learned the hard way) to not accept any content
that requires specific permissions to run.


> Jon Schuster wrote:
> > The suggestion that others have made to make the search web based is
> > generally the preferred route.
> >=20
> > But it is fairly straightforward to make an unsigned applet=20
> use a remote
> > Lucene index. You wouldn't need to write the index and PDF=20
> files to the
> > local disk; you only need to be able to open an input stream to the
> > server location where the index files are stored, which you=20
> can do using
> > URL.openStream. If the applet is unsigned, security=20
> restrictions would
> > require that the index files be under the applet's=20
> codebase, but it's
> > easy to determine the codebase URL. After the desired=20
> document is found
> > by the search, you can then use AppletContext.showDocument=20
> to open an
> > URL to the appropriate PDF file.
> >=20
> > There are some gotchas if you use an applet, however. For=20
> one, the index
> > needs to be downloaded in order to search, and an index=20
> that's 1-2 MB
> > might take too long for a user to wait. Further, to avoid applet
> > security restrictions on reading and writing local files,=20
> you probably
> > need to use either a non-locking index or a RAM directory. Also, in
> > Lucene 1.4, there are a few classes that attempt to read system
> > properties, and these also run into applet security=20
> restrictions unless
> > the classes are modified (this last issue has been=20
> addressed in the next
> > release).
> >=20
> >=20
>=20
> I'm confused between paragraphs 2 and 3.
>=20
> In 2, you say that I don't need the index on the local=20
> machine, just an
> openStream to it.
>=20
> In 3, you say that I need to download the index in order to search.
>=20
> I have no problem signing the applet, if it will make this project
> feasible.  And downloading the index isn't that horrible either, as I
> can make it only happen once a day, not everytime they connect.
>=20
> Thanks for the information.
>=20
> Dave in Largo, FL
>=20

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