[sword-devel] free Windows compiler for SWORD

[Troy A. Griffitts]

Joel,
	After searching through my emails and extracting the bits that I feel 
support my 7/17 email, the result is attached to the end of this 
message.  There were many irc sessions that I feel also added quite a 
bit, but I have no history of those conversations.

Though I understand your frustration, I don't appreciate you taking pot 
shot on the public email list (other emails before this most recent one) 
about your searching not getting implemented.

I value the fellowship, challenges, trials, and other growing 
experiences that we all have with each other on CrossWire projects. 
They are probably more valuable than the actual software.

I was not looking for a 'yes-man developer', but someone who would 
appreciate my convictions and honor them.

You are an enjoyable person, a good engineer, and even a good architect. 
  I have nothing against you, save for:

1) your persistence with a subject of disagreement
2) your _public antagonizational voicing_ of complaints (even if warranted)

It's very much a fun thing to architect a solution to a problem.  The 
grunt work of building the solution is not the most glorious.  My hope 
is that people will be creative with their architecting of their 
solutions WITHIN the existing API framework.  I understand that you have 
many good ideas for change; some on which we agree, and some otherwise.

People submit code to SWORD all the time.  Many people have direct 
access to commit code without my approval.  But they all understand that 
the FRAMEWORK is set, and adding dependencies is not acceptable.  New 
markup filters are added and changed all the time, as well as option 
filters (for stuff like footnotes, strongs, etc.).  These are easy to 
allow because they are all plugins into the framework and can be easily 
removed.  Being a revolutionary isn't a bad thing, but just not an easy 
thing to facilitate.

When you started the search work, there was a search plugin framework in 
place-- even if it sucked.  Your code did not unintrusively use this 
framework to isolate itself.  I liked your ideas toward a possible 
different way to allow search plugins.  My last statement to you was:

if we allowed this search registration method, I would have no problem 
making this search type (with all its extra code) available as an 
additional plugin.  The patch would be almost non-intrusive (save for 
the registration call), and the rest would be extra files.

You responded that you wanted more of my time before you would be 
willing to do this.  Without a clean cut isolation of your work, I can't 
even consider including it with the extra parsing code.  Even IF it was 
an additional component of a search framework, I would still have issues 
with including a 3rd party library just for logic parsing, but my 
statement above still stands:  if it can be extracted as an addon search 
type, I would concede to include your search code even with the extra 
3rd party library.

My apologies for the delay this reply has seen getting to you-- and for 
all the lapses that drew this task out.  If I had the time and priority 
to redesign the search framework, I would have done it myself.  I'm not 
sure how to facilitate it when another person wishes to do this before 
me.  There is alot I still have to learn about facilitating aspects of 
this project.  I hope this recent trial hasn't broken our relationship.

	-Troy.




Troy A. Griffitts wrote:
> Joel,
>     Public comment deserves public response:
> 
>     Over the 2 months that you worked on your extensions to the Search 
> code

8/25/2002 - 10/30/2002


, we had numerous emails / chat sessions about what I would not
> accept in the engine, namely: 1) adding 2 megs of source code of someone 
> elses project just to parse logic syntax; 

8/29/2002: me: Remember, we compile on a variety of platforms, including 
handhelds, and have many components that are useful independently of the 
rest of the API.  Adding requirements of external libraries across the 
board in the API is a very serious thing to consider."

9/30/2002: you: Hi all,

I'm writting to get reactions to the idea of making sword dependent on 
ICU. Currently we only have optional dependencies on ICU (at least for
transliteration but I'm not sure what else). I would like to suggest 
making ICU required for sword.

10/01/2002: me:
My position on ICU:

We use it in the engine.  It is never exposed in the engine and is 
always optional.
...
I am not willing to make a dependency on icu.
[suggestions how to encapsulate icu functionality]

10/01/2002: you:
I wish it was that easy. (grin) But seriously, I forsee a growing number 
of cases like this. I would suggest that just biting the bullet and 
using the ICU functionality will be better in the long run...

10/26/2002: you:
I just discovered that the version of the parser framework I've been 
using may not be compatiable with MSVC++

10/30/2002: you:
[attached search patch]
Here are my changes to look at and try.
...
I still have two unresolved issues:
...
2. Will the version of the Spirit parser framework I used work with 
MSVC++ and C++ Builder?

[long pause with much apologies along the way]

2/22/2003: me:
 From a brief look at your work:
...
I don't like the more than .5 megs of added source which is mostly the 
expression parser.

[2 megs was an unwarranted exageration and deserves an apology, but the 
point still stands]

you:
Are you concerned about the source code size increase or the executable 
size increase? Personally I don't see a code base increase as that big a 
deal



 > 2) changing the API interface to expose a new 'search' object.

8/29/2002: me: Well, I'm hesistant to allow anyone to make 'signicant 
changes' to any part of the 'model' of the engine-- as you would expect. 
  I'm not sure if you are aware, but we have a crude extraction of the 
search mechanism to allow drivers to implement their own fast searching 
architecture.

me: ...I would understand this to be in your implementation of the 
search mechanism and not part of the end user api.

you: Yes, you are correct.

9/03/2002: you: I think a lot more functionality could be exposed to the 
API clients than is possible with a single search method.

me: Like what?  I'm not opposed to adding additional searchType values.
9/4/2002: you: By exposing more fine grained control to the frontends 
you can do a bunch of neat things. For example say SWIndex had these 
methods:

ListKey* search(some options here)
ListKey* AND(ListKey* a, ListKey* b)
ListKey* OR(ListKey* a, ListKey* b)
ListKey* NOT(ListKey* a)
ListKey* PROXIMITYAND(ListKey* a, ListKey* b, int proximity)

9/16/2002: me: I'm mostly concerned with:

a) the syntax used in the new search type
b) the parser of such and the core api implementation in SWModule::Search.
...It doesn't affect the interface of the API...

2/22/2003: me:
 From a brief look at your work:

I like the idea of an abstract class to handle search types.
I don't like the idea of making it publicly accessible in the api
...
It seems a promising architecture would be to allow a searcher to 
register itself as a 'search type' and SWModule::Search could see if it 
had a matching searcher registered to handle the search type.
[other comments conceding interface changes to the search plugin arch to 
allow your patch as an optional ADDON, but not changes to the client's 
interface for _using_ searching]
...
if we allowed this search registration method, I would have no problem 
making this search type (with all its extra code) available as an 
additional plugin.  The patch would be almost non-intrusive (save for 
the registration call), and the rest would be extra files.

2/22/2003:you:
What I don't like about the current way SWModule::Search() works is that 
each search type and module impl is forced to use the parameters and 
return type that Search() defines in SWModule.

> 
>     I appreciate the work, and when I get around to changing these 2 
> major issues, I still plan to integrate your code into the engine, BUT 
> it was a constant fight with you the entire time of development.

(to your credit)
8/29/2002: Put up a good fight and you'll win our confidence, ESPECIALLY 
if you show you're here to stay!


 > I explained in detail how I felt on these issues and you still chose to
> submit your code in this format.  You also repeatedly ignored my 
> suggestions regarding implementation of other things (including keeping 
> the code in the same theme as the existing Search code, so Range 
> searching will work in the future).

8/29/2002: You are free to implement your search functionality in any 
way you see fit, even requiring ICU if you desire.  This would mean that 
your mechanism wouldn't be available to people without ICU, but maybe 
you're not concerned with this.  I would encourage you to consider a 
non-icu implentation for use with western scripts, but that's a later issue.

[I'm sure we had at least 2 chat sessions about the 'range' issue.  To 
be more specific: e.g. "within 3 verses".  I had asked if you would 
implement your logic the same as what was in SWModule::Search, so when 
we implemented this range thing they way I explained it would be impl'd, 
your stuff would work.  I don't remember the details, but do remember 
being a little frustrated when I looked at your code and it wasn't 
impl'd this way]


   If you want your code integrated
> into a project, I feel you might need to respect the requests of the 
> maintainer, or expect to wait until the maintainer has the time to do 
> what you would not do, before the code is added to the project.  I just 
> haven't had time to do this.  You've known this entire time what issues 
> I have with your code, and you have a right to disagree with my 
> opinions, but don't expect me to integrate it in this form into a 
> project for which I hold responsibily.
> 
>     Your time and work are still appreciate,
> 
>         -Troy.
> 
> 
> 
> Joel Mawhorter wrote:
> 
>> On July 16, 2003 17:39, Chris Little wrote:
>>
>>> Seriously, the single greatest problem with Sword is probably the
>>> inordinate ratio of people crying for new features to the number people
>>> they expect to implement them.
>>
>>
>>
>> This is easy to say. However, until new developers are able to be 
>> integrated into the development process without an unreasonable amount 
>> of effort, this will remain exactly as it is. If my experience trying 
>> to improve the searching in Sword is representative of what other 
>> prospective developers have had to go through then it is no surprise 
>> to me that the Sword development team is small. Of course it is 
>> perfectly within the rights of the maintainers of a project to keep 
>> the development team small. However, if you do, recognize that a large 
>> ratio of people requesting features to people contributing code is 
>> probably a consequence of that decision.
>>
>> Joel
>>
>>
>>> --Chris
>>>
>>
>>
>> _______________________________________________
>> sword-devel mailing list
>> sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
> 
> 
> _______________________________________________
> sword-devel mailing list
> sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel