[sword-devel] mod2zmod problems
Troy A. Griffitts
Sat, 13 Jul 2002 13:34:14 -0700
> would it not be better to wait with the entyattribute stuff until the sword
> api is redesigned (2.x -- not talking of BibleCS)?
No, the redesign will not alter the EntryAttributes concept or the
'meat' of any functionality in 1.5.x. The redesign will simply change
the programming interface to be consistent, and many of the concepts
that I've wanted to add at redesign time have already been started in
the 1.5.x branch.
> IMHO a unsound mix of filtering and direct acess would be created if we would
> start using this thouroughly now, because those are very different approaches
> to access the text.
? Not sure what you mean. The filters produce the EntryAttributes
entries. There is no direct access. The filters are still involved in
formatting the EntryAttributes entries the way your frontend requires
them (or should, when they are actually written/complete).
> Before doing this, we should probably switch to OSIS
> internally, and then redesign the api to give it a more consistent and
> flexible approach.
Actually, you, as a client of the API should never have to know that any
text you use is in OSIS, or ThML, or GBF, or whatever. Only as an API
extender (filter writer, etc.) or hacker should you have to know about it.
> The entryattribute stuff seems to be much similar to the
> ontag mechanism you planned for sword 2.x.
> Please correct me if I am wrong here, I might be misinformed.
Well, actually, the onTag mechanism was intended for filter writers to
more easily write filters by responding to tag instances with an onTag
event. The design will also allow us to consolidate cases where we
currently have mutliple passes of the text by multiple filters into a
single pass, hopefully speeding up things considerably.
> Btw, do we have the list of sword "module.conf" keys online? I would like to
> submit it to the wiki.
Yeah, I think Chris posted the current list a few months back. I'd
check the archives (I'm assuming you mean valid .conf entries, and NOT
the CipherKey's :) ).
Thanks for the feedback. I hope this clears things up a little. Value