First, I apologize for not being more involved with the day-to-day development of DQSD. I'm the dude responsible for the first 'add-on' thingy, and it was meant to serve as a way to allow people to add functionality without bloating the app. It was really the same reason I added the ability to put searches in their own files way back when. But, because we deliver and install all the searches, and don't an easy way to disable loading searches, this benefit (non-bloat) isn't being realized.
I'm convinced that unless someone has the time to completely overhaul DQSD with this plug-in/hook design in mind from the beginning, we won't be able to achieve much more than we already have. Everybody is still essentially hacking on the the original search.htm that was there when all DQSD consisted of was search.htm. Right now, I don't want _my_ installation of DQSD to display an RSS ticker, a weather report, a POP3 notifier/email client, etc. I just want to search. But, if an architecture can be put in place that allows this and any other yet-to-be-imagined add-ons _without slowing my searches down_, I'm all for it. But the architecture is the key, and the current architecture is a hinderence, not a help. Before it can be better, it is going to take some dedicated effort from someone(s). If I had the time, I would start development on a new search bar, not building on top of the current one. Do some investigation into how Google is doing theirs, and any other necessary research. Personally, I would love to get rid of the script that is driving the core, and do it all in C++ so that all the stuff that the current DLL does could be combined. I know most don't like this, but the DLL is really what makes this thing tick right now, thanks Will Dean and other the other developers that have hacked on that thing. Anyway, it's just going to take a some dedicated time from some core developers to put this thing on the right track. I wish I had the time, but I don't. Glenn ----- Original Message ----- From: "Kim Gr�sman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 02, 2004 8:32 AM Subject: RE: [DQSD-Devel] New feature / roadmap? > Hi Shawn, > > > If you've written several searches (I have) you've had to. If you've > > written any 'functional' searches (I have) then you'd see how much > > more appealing it is to add *some* code to the core to enable the rest > > of the code you write (and everyone else writes) to be as minimal as > > possible. Before I found pareArgs I was doing it all myself - what a > > waste of space! > > Amen! > > Now I better understand what you're advocating, and I agree. I definitely > think DQSD needs a more well-defined interface toward search authors and > add-in authors, so core functionality is available to them. > > I'm not sure how to best realise this, and I'm a little pressed for time at > the moment, there's a lot going on in my other (non-OSS) life :) > > Also, deciding on what actually is core functionality might become > interesting, there seem to be a couple of different views on this, but it's > nothing we can't figure out. > > Thanks for clarifying, > Kim ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ DQSD-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dqsd-devel
