On Mar 13, 2007, at 6:22 AM, Eeli Kaikkonen wrote: > On Mon, 12 Mar 2007, Karl Kleinpaste wrote: >> For the record, GnomeSword handles this in (what can be) a general >> way: GS handles "sword://" URLs as clickable references. GS >> understands "sword://ModuleName/KeyIntoThatModule" where the key is >> obviously a verse reference for Bibles and commentaries, but just as >> easily is a treekey for genbooks and lexdicts. > > BTW, has anyone thought of having > "sword://localhost:1111/ModuleName/Key"? Would it be too hard to > make a > sword protocol which could be used through net? It would be great to > have have some often-used modules local and then use occasionally some > modules online from a server.
I don't think this would be too hard to do. From my perspective (a JSword developer) the front-end GUI application is a browser of modules with an address bar. That is, the user can input a request for a range of passages and it will display those passages. With JSword, I have played with embedding IE and FireFox as the display engine for BibleDesktop. I have been able to install a protocol handler for bible:// to handle the URI and display the content of the OSIS ref. (We also have other protocols we use) Perhaps it is possible to do the same to a non-embedded browser. At least on the Mac it can be done. MacSword has installed a protocol handler into the Safari web browser so that the sword:// urls are passed off to MacSword, starting it if it is not running, rather than displaying them in the browser. (It doesn't work very well and I can get it to crash MacSword) So as I see it the pieces of the puzzle are: The client machine: 1) has a protocol handler that can be installed to the OS that will pass the URI to the a running instance of the protocol handler, starting it if necessary. 2) The protocol handler will interact with running applications that can display the content of the URI. If none is running, it will start the user's preferred browser application. 3) The user can establish a preferred browser application. 4) The browser application can handle the URI, passing it to the server and getting a response. The server machine (which may be the client machine) has a server application (which may be the client application) which: 1) can receive requests, get the data and return it to the client application. In this there is a need to have a well-defined protocol and URI specification that all applications share and for all Sword apps for a given platform to play together. Today, each front-end does it's own thing, ignoring all other front-ends. _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
