[jsword-devel] Sword drivers - a new way of doing things.

[Troy A. Griffitts]

Joe,
	No no, it's not a question of priority, really.  It just seemed that 
Mark commented on 'maybe' making the classes a little more 
'traditionally' sword-like, in such a way that he though it was a novel 
idea and not a planned goal.  I wasn't sure if people knew that 
refactoring the API to be more sword-like was an eventual goal.  And you 
know my stance--  the jsword-old cvs repository is our beginnings of the 
jsword port and is a class by class port of the C++ code.  We continue 
to update this repository because the website uses it to obtain the 
module list and configuration information, just like the C++ api.  I had 
to rollback some code that was submitted and never completed regarding 
SWConfig (back to using jgl), but for the most part has updates that 
others have submitted, as well.

	When I mentioned first priority of 'getting jsword to read a standard 
sword module install set', I meant all module types, including lexicons, 
etc.  So I think we are even still in agreement regarding priority.

	Thanks for everything.  I think you guys rock!

	-Troy.



Joe Walker wrote:
> 
> Hi,
> 
> It is definitly an eventual goal.
> 
> I have already done some work in renaming some classes - for example 
> there is now a Key class. Further work is still planned to update the 
> sword tree (which is and should remain very Sword compatible) to proxy 
> to the JSword tree. This way users get the best of all possible worlds. 
> Anyone wanting to write Java code using the C++ Sword API could do so, 
> but we don't have to re-architect everything and (in my opinion) loose 
> some of the benefits of the Java way of doing things.
> 
> So the question of priority - personally I'm more aware of people 
> wanting support for Lexicons, properly working JNLP, etc than I am of 
> strict API compatibility. I'd planned to work on the C++ compatible API 
> when someone wanted to use it mostly because it's not a itch for me 
> personally.
> Is there anyone out there wanting to write code to it right now? If so I 
> don't mind reprioritizing things a bit.
> 
> Joe.
> 
> 
> Troy A. Griffitts wrote:
> 
>> Hey guys.  This might be a touchy question...
>>
>> but, wasn't the 2nd thing on the priority list (after getting jsword 
>> to read a standard sword module install set) to make the class hierchy 
>> and api, in general, similar to sword?
>>
>> With this said...  I'm glad Mark is considering a modular approach 
>> similar to the sword engine.
>>
>> Just wondering if this was still an eventual goal.
>>
>>     -Troy.
>>
>>
>>
>> Mark Goodwin wrote:
>>
>>> Hello people.
>>>
>>> I wasn't supposed to have time for this, but I couldn't sleep last
>>> night......
>>>
>>> Some changes will be neccesary in SwordBible and SwordBibleDriver if we
>>> are to cope with the many different types of Sword Bible in a tidy and
>>> efficient manner.
>>>
>>>> From looking at the different types of modules, and different kinds of
>>>
>>>
>>> markup, it occurred to me that it would be a good idea to split Sword
>>> Bible handling into a set of backends (raw, zip, encrypted), and
>>> frontend with access to a set of filters (ThML, OSIS, GBF, etc.) much
>>> like 'original flavour' Sword, in fact (I've not spent very long looking
>>> at the code, but that's the idea I got).
>>>
>>> We could then have a single frontend, which loads filter classes
>>> according to parameters in the module config file, and delegates to the
>>> backend for the purposes of loading data.  The data returned from the
>>> backend would be passed through the relevant filter(s) for removal /
>>> translation of markup, and presented using a normal Bible interface.
>>>
>>> Anyway, I spent a couple of hours hacking on some prototype code - I've
>>> not addressed Filters yet (these would be loaded and used by SwordBible
>>> itself), but the rest is there in concept.  There's a new way of loading
>>> and representing Sword module configs in all (well, most of) their
>>> complexity, Raw modules work fine, and I've put some stubs in to
>>> demonstrate that the new SwordBibleDriver can 'see' compressed texts as
>>> well.
>>>
>>> I've not committed to the trunk because a) it's messy prototype code,
>>> and b) I'm not going to have time to do anything it for a few days. If
>>> you're curious or feel like doing some work on the Sword module support
>>> yourself then have a look at the contents of the following branch:
>>> mdg_sword_drivers_20021017
>>>
>>> Beware of the bit with comments that say TODO and URGENT :-)
>>>
>>> Finally, if you want to work on this stuff and you're not sure on how
>>> the Sword modules hang together, contact me telling me what you want to
>>> do - I've got heaps on info I've gleaned on various things (I also made
>>> a stab at deciphering the zverse stuff in sword). I've also got some 
>>> code for LZSS compression stuff, and documentation
>>> etc. on Sapphire II for the locked modules.
>>>
>>> Have fun.
>>>
>>> MarkG
>>>
>>>
>>>
>>> _______________________________________________
>>> jsword-devel mailing list
>>> jsword-devel@crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>>
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
> 
> 
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel