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 [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
