J2ME bible (was Re: [jsword-devel] Re: Unable to check out from CVS)

Jacky Cheung jsword-devel@crosswire.org
Sun, 11 May 2003 20:03:35 +0800


--------------000200080309010806030809
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I think it is possible to have a SOAP interface which is very different 
from existing Bible or Book interface.

We can implement a SOAPRemoter and SOAPRemoteBookDriver to talk to the 
server through SOAP interface. There is a HTTPRemoter and 
HTTPRemoteBookDriver in org.crosswire.jsword.book.remote package which 
does similar thing with plain HTTP.

Jacky

Eric Galluzzo wrote:

>On Fri, 2003-05-09 at 20:28, Jacky Cheung wrote: 
>  
>
>>Agreed. Some devices (like J2ME Phone) are too small to store a bible.
>>We need to search and retrieve them from Internet. For PCs, why we
>>need to install bibles at all if we can also search and retrieve
>>bible, dictionary, and commentary from Internet? When I was studying
>>bible, I can just read the text of other bible version immediately
>>without worrying about installing them. I can read BDB if I wanted to
>>study the meaning of the original text.
>>
>>We can achieve it in this manner...
>>For bible services,
>>1. register itself to UDDI server on startup
>>2. serve for requests from clients
>>
>>For the clients,
>>1. find all bible/dictionary/commentary web services from UDDI server
>>2. select one of the service (may be the program select it ramdomly)
>>3. connect to the service and get information (which bible is
>>supported) about it
>>4. do search/retrieve whatever the user want
>>
>>Web services need not host every bible version. But we can access any
>>bible (at least those popular) if their enough people willing to host
>>bible for the use of others.
>>
>>Yes, there are much to do and maybe out of the scope of this project.
>>But it is really worth doing and I think there is nobody else doing
>>something similar.
>>
>>What do you think?
>>    
>>
>
>Wow, that is a _really_ neat idea!  I hadn't thought of using UDDI. 
>Now, for J2ME purposes, we probably still couldn't do that, because as
>far as I know there isn't a UDDI parser for the KVM (although UDDI isn't
>that complicated, so it might be feasible for us to write one).  But for
>desktop purposes, that sounds great!  For laptops and such where one is
>frequently offline (e.g. in the plane), it would still be good to
>support local Bibles, commentaries, etc.
>
>What would the interface be?  SOAP does impose some design constraints
>upon one's interfaces (e.g. no Lists or Iterators, just arrays), but
>apart from that could we not use the current JSword Book or Bible
>interface as the SOAP object to expose?
>
>	- Eric
>
>_______________________________________________
>jsword-devel mailing list
>jsword-devel@crosswire.org
>http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>  
>


--------------000200080309010806030809
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
I think it is possible to have a SOAP interface which is very different from
existing Bible or Book interface.<br>
<br>
We can implement a SOAPRemoter and SOAPRemoteBookDriver to talk to the server
through SOAP interface. There is a HTTPRemoter and HTTPRemoteBookDriver in
org.crosswire.jsword.book.remote package which does similar thing with plain
HTTP.<br>
<br>
Jacky<br>
<br>
Eric Galluzzo wrote:<br>
<blockquote type="cite"
 cite="mid1052589023.3723.16.camel@localhost.localdomain">
  <pre wrap="">On Fri, 2003-05-09 at 20:28, Jacky Cheung wrote: 
  </pre>
  <blockquote type="cite">
    <pre wrap="">Agreed. Some devices (like J2ME Phone) are too small to store a bible.
We need to search and retrieve them from Internet. For PCs, why we
need to install bibles at all if we can also search and retrieve
bible, dictionary, and commentary from Internet? When I was studying
bible, I can just read the text of other bible version immediately
without worrying about installing them. I can read BDB if I wanted to
study the meaning of the original text.

We can achieve it in this manner...
For bible services,
1. register itself to UDDI server on startup
2. serve for requests from clients

For the clients,
1. find all bible/dictionary/commentary web services from UDDI server
2. select one of the service (may be the program select it ramdomly)
3. connect to the service and get information (which bible is
supported) about it
4. do search/retrieve whatever the user want

Web services need not host every bible version. But we can access any
bible (at least those popular) if their enough people willing to host
bible for the use of others.

Yes, there are much to do and maybe out of the scope of this project.
But it is really worth doing and I think there is nobody else doing
something similar.

What do you think?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Wow, that is a _really_ neat idea!  I hadn't thought of using UDDI. 
Now, for J2ME purposes, we probably still couldn't do that, because as
far as I know there isn't a UDDI parser for the KVM (although UDDI isn't
that complicated, so it might be feasible for us to write one).  But for
desktop purposes, that sounds great!  For laptops and such where one is
frequently offline (e.g. in the plane), it would still be good to
support local Bibles, commentaries, etc.

What would the interface be?  SOAP does impose some design constraints
upon one's interfaces (e.g. no Lists or Iterators, just arrays), but
apart from that could we not use the current JSword Book or Bible
interface as the SOAP object to expose?

	- Eric

_______________________________________________
jsword-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel</a>

  </pre>
</blockquote>
<br>
</body>
</html>

--------------000200080309010806030809--