Grant Ingersoll wrote:
Came across:
http://www.google.com/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2Fgroups.google.com%2Fgroup%2Fandroid-developers%2Fbrowse_thread%2Fthread%2F601329551a87e601%2Fcd0919ce891b4a26%3Flnk%3Dgst%26q%3Dlucene&ei=zNzcSPHCF4yI1ga61YiTBA&usg=AFQjCNECrBnNPBkxI4I0EbIzI-mNp3S4YA&sig2=4sDMmwa9Mrk38Nla_ULtOg
The gist of it is, that on Android doesn't provide the RMI package.
Thus, Lucene core can't work on Android b/c of Searchable extending
java.rmi.Remote.
This has always seemed a little weird to me. I'm no RMI expert, but
couldn't we drop the extension on Searchable, and add it to
RemoteSearchable, and then move RemoteSearchable and all the RMI stuff
to a separate contrib? This, in my view, would be consistent with
keeping core, core, since not many people, I think, even use the RMI
stuff and it certainly isn't required in most cases.
I haven't looked into what would break in doing it, so it is just a
suggestion at this point. Seems like it could be "mostly"
back-compatible, though, since we would just be requiring someone to get
the new JAR, unless of course they implemented their own extension of
Searchable that relied on the Remote marker interface.
Thoughts?
Even more, I wonder how many people use RemoteSearchable in real
applications. If it's in a relatively small number of cases, then let's
move it to contrib - so long as we remember to keep all search-related
core classes Serializable ;)
I recall a single situation when I had a use for remote searchable, and
due to the operational issues with running rmiregistry we went with a
custom RPC anyway.
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
