Hi Brent,
> I think there should be a distinction between the
> implementation (ie a weather rss feed displayer) and
> the code needed to support something like this.
Exactly.
I'm not asking for stuffing an RSS feed or a search *into* search.htm,
but rather, asking for a simple change (in clock.js) - from this:
'// ========================================================
function startclock(delay)
{
if (clock && !clockrunning)
{
clocktimer = setTimeout("advanceclock()", delay);
clockrunning = true;
}
}
'// ========================================================
to this:
'// ========================================================
function startclock(delay)
{
if (typeof clockevent == "undefined")
clockevent = "advanceclock()";
if (clock && !clockrunning)
{
clocktimer = setTimeout(clockevent, delay);
clockrunning = true;
}
}
'// ========================================================
It's not a major code overhaul. It *does*, however, provide the
abilities to the people creating functional searches (not just
web-searches) to "do things" on the system instead of just a basic
search, without having to code up an additional 30 or 40 lines for
each search. It also gives the user a more customizable interface.
They could add anything they wanted to "clockevent" at this point -
and it would not have to be coded up any special way, nor would it
have a second (or third, or more) timer event firing, effectively
sucking up even more memory.
Here's a few examples:
// to open/refresh a browser window to your website stats page
clockevent = "window.open('http://example.com/stats/','stats')";
// update an inline rss feed (assuming the search 'rss' exists)
clockevent = "rss('http://example.com/rss')";
// use the default clock (or remove the clockevent line):
clockevent = "advanceclock()";
// mix and match:
clockevent = "window.open('http://example.com/stats/','stats')";
clockevent += ";rss('http://example.com/rss')";
clockevent += ";advanceclock()";
// that would do the rss feed, the stats and the clock
> So I think that if the changes are relatively small,
> don't slow down general use, and allows add-ons to do
> amazing new things that we could add it into the core.
This is exactly my position.
How many people here have actually created an addin to add the
abilities they wanted? For those of you that have created addins (yes,
I know it's a small group), how many of you have had to duplicate
functionality within the addin to insure it was available to DQSD,
since the same functionality was not built into it?
I've looked at the sources for the published addins. There *is*
duplicate code. Between two of them the duplication amounts to over
50kb. That's a lot. Especially when compared to a 77 byte change.
Same goes for search authors. How many of the search authors have
duplicated methods, functions or inline code that does the exact same
thing, since it isn't in the DQSD core?
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! Now I use parseArgs when I can, but it doesn't handle
everything. Not even close!
So what if Joe Blow isn't going to use the method directly - 99% of
the rest of our users installed all searches (actually, all of them
did, Joe was just one of several to actually remove stuff) and had
significant amounts of duplicate code eating up that valuable memory
we're *all* trying to protect.
My point is that if you really want to make things with the smallest
footprint that *also* provides the greatest extensibility for our
developers and users, we need to provide a number of hooks to the core
engine for code that would otherwise cause either significant
duplication or bloat if anyone wanted to implement it. Make the
internal library as dynamic as possible and revert to defaults when a
value is not specified.
Maybe we ought to start building a list of core functions that ought
to be exposed to developers, too. Like 'trim' (it's a simple enough
RegEx but I've had to duplicate it in just about every search I've
made). parseArgs and parseArgsEx are both nice, but they don't let us
accomplish all we need to - and if I've got to recode another method
to handle *allowing* "/" in the value of a param, then it may as well
go into the core since I *know* other people have needed similar
functionality (Tom, for one).
I'm not wanting to make unnecessary changes to the project, quite the
opposite - I'm wanting to make this as simple as possible to develop
for, and provide search/function developers with code templates, a
library of useful internal functions, while *also* providing users
with the easiest user-preference management possible. If every search
developer has to 'do their own thing' to make it happen then it is
harder to administer (as each has it's own custom stuff) and doesn't
provide the same potential range of abilities.
Is there any form of development roadmap of features and functions
exposed and bugs fixed by a specific version? I envision a lot of
changes - which I think we ought to consider mapping towards as goals.
Again - "good" changes. Like providing better search load parsing with
an XML handler. Reduce the memory overhead by only loading into memory
what is necessary. Remove spaces as alignment characters and use tabs
instead (this would reduce my current memory load for search.htm from
153046 bytes to 147058 - a savings of ~6kb just by replacing space(2)
with tab(1)). DQSD's own protocol handler (qs://) that can be called
from links. Moving resource files into the appdata folders. Providing
a UI-based editor that is 'aware' of the settings variables (these
could all be exposed within individual searches within an xml
structure that also provided details about the variable and sample
values). Add the ability to create certain activex object references
by name from within searches using the launcher class. The ability to
run dqsd from a webpage without having it installed (how many times
have you all wanted to be able to use DQSD when you weren't at home or
work?).
This is all stuff that can be done. Most of it relatively easily. Some
of it not so easily, but easier to plan for with a roadmap. Changes to
some of the search files would be necessary to provide a clean and
manageable, consistent xml file format. Yeah, in some respects it
might be a lot of work, but it's better to plan this kind of thing as
far ahead as you can.
<sigh />
Regards,
Shawn K. Hall
http://ReliableAnswers.com/
'// ========================================================
"The time has come," the Walrus said, "To talk of many
things: Of shoes and ships and sealing wax, of cabbages
and kings, and why the sea is boiling hot, and whether
pigs have wings."
-- Lewis Carroll
-------------------------------------------------------
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
