| |
In lugnet.admin.general, "Robert Munafo" <munafo@gcctechNO.SPAMcom> writes:
> In lugnet.admin.general, Jeremy Sproat writes:
> > [...] I haven't been able to figure out how to use it; e.g., what is
> > the syntax to, say, modify the query to prefer articles from about four
> > months ago?
>
> It appears that for now we just have the recent (default) target time and
> 1-week sigma values. If there is a syntax for overriding these, Todd hasn't
> chosen to tell us about it. I would guess that it isn't yet ready for general
> use.
A syntax vis-à-vis URLs isn't yet defined, but how does this sound?--
There's currently q= for the query string:
http://www.lugnet.com/?q=jeremy+sproat
and qn= for subsequent pages of results:
http://www.lugnet.com/?q=jeremy+sproat&qn=60
so there are still 25 possibilities in the q*= namespace. How about qt= for
the target time and qs= for the sigma (provided that some other non-greek
mnemonic can be identified for 's'):
http://www.lugnet.com/?q=jeremy+sproat&qt=-10519200&qs=2629800
4 months is about 10519200 seconds, and 1 month is about 2629800 seconds, so
that query would mean "prefer articles from about four months ago, with a
preferential spread of about a week or two either way."
For clipping absolute time ranges, how do qt0= and qt1= sound?--
http://www.lugnet.com/?q=jeremy+sproat&qt0=-1814400&qt1=-0
with the sign of qt0-qt1 specifying the sort order, chronological or reverse
chronological.
As far as the numerical values themselves go, they could absolute times in
the standard epoch format (seconds since 1 Jan 1970 00:00:00 GMT) or
relative times or both, or expressed in hours or days instead of seconds.
I'd favor seconds and standard epoch time, with a transparent query
generator page. That is, say the advanced search page is at /news/search/,
and you specify "about 4 months ago." Then it should calculate the current
time minus 10519200 seconds for you automatically, and do a double-CGI call:
first to process the form and convert "4 months" into 10519200 and second to
respond to the query itself. (I wouldn't want to litter the URL line with
all of the possible options present on the actual human-interface form
because it's important to keep the URLs short and to separate (abstract) the
query interface layers.)
So when you click the Go button on the advanced search page, it would do
that via HTTP POST (not GET), and that script would interpret the query, and
rewrite it into a URL which gets spit out via a Location: header to enact
the actual query. (It would be 99% transparent -- all you'd actually see in
your browser is "contacting host..." twice in rapid succession.)
In the URL parser, positive values for time could be interpreted as absolute
values and negative values for time could be interpreted as relative values
(relative to the current time).
--Todd
|
|
| |
Todd Lehman wrote:
> In lugnet.admin.general, "Robert Munafo" <munafo@gcctechNO.SPAMcom> writes:
> > In lugnet.admin.general, Jeremy Sproat writes:
> > > [...] I haven't been able to figure out how to use it; e.g., what is
> > > the syntax to, say, modify the query to prefer articles from about four
> > > months ago?
> > It appears that for now we just have the recent (default) target time and
> > 1-week sigma values. If there is a syntax for overriding these, Todd hasn't
> > chosen to tell us about it. I would guess that it isn't yet ready for general
> > use.
> A syntax vis-à-vis URLs isn't yet defined, but how does this sound?--
> [snippage of URL syntax]
> I'd favor seconds and standard epoch time, with a transparent query
> generator page. That is, say the advanced search page is at /news/search/,
> and you specify "about 4 months ago."
Sure, sounds okay. I'm a little nervous about handling raw seconds; the big
numbers make my puny earthling brain hurt. :-, How about using the same
syntax used in the traffic report page; e.g.
http://www.lugnet.com/news/traffic/custom.cgi?hours=6
Shows what's happened in the past 6 hours. How about something like
http://www.lugnet.com/?q=jeremy+sproat&qtmonths=6&qsdays=7
to ask for the results to prefer articles submitted a month ago, with s
spread of 7 days? Hmmm... There would be lost flexibility then, as you can
only ask for integral values of one time metric. Arg. I'll have to
surrender to the intellectual superiority of my browser. :-P
> (I wouldn't want to litter the URL line with
> all of the possible options present on the actual human-interface form
> because it's important to keep the URLs short and to separate (abstract) the
> query interface layers.)
I don't think it matters, really. With the URL for something more or less
static (like an article), this is true, but we're talking about search
queries here. With regards to time, searches are very volatile stuff.
> So when you click the Go button on the advanced search page, it would do
> that via HTTP POST (not GET), and that script would interpret the query, and
> rewrite it into a URL which gets spit out via a Location: header to enact
> the actual query.
I like this idea. It'd let you totally separate the query interface from
the actual engine, allowing for gobs of changes to either end, needing
probably minimal changes to the glue-layer CGI.
Cheers,
- jsproat
--
Jeremy H. Sproat <jsproat@io.com>
http://www.io.com/~jsproat
Darth Maul Lives
|
|
| |
Do we REALLY need the precision that seconds bring us? :-)
I'd vote for days or at least hours. Even for a non human readable API
like this one, go with data that's understandable to humans and let the
machines keep the books straight.
--
Larry Pieniazek larryp@novera.com http://my.voyager.net/lar
- - - Web Application Integration! http://www.novera.com
fund Lugnet(tm): http://www.ebates.com/ Member ref: lar, 1/2 $$ to
lugnet.
NOTE: I have left CTP, effective 18 June 99, and my CTP email
will not work after then. Please switch to my Novera ID.
|
|
| |
In article <37c311a6.412616938@lugnet.com>, Todd Lehman
<lehman@javanet.com> writes
>
> A syntax vis-à-vis URLs isn't yet defined, but how does this sound?--
<snip>
>
> http://www.lugnet.com/?q=jeremy+sproat&qt=-10519200&qs=2629800
>
> 4 months is about 10519200 seconds, and 1 month is about 2629800 seconds, so
> that query would mean "prefer articles from about four months ago, with a
> preferential spread of about a week or two either way."
>
> For clipping absolute time ranges, how do qt0= and qt1= sound?--
>
> http://www.lugnet.com/?q=jeremy+sproat&qt0=-1814400&qt1=-0
>
> with the sign of qt0-qt1 specifying the sort order, chronological or reverse
> chronological.
<snip>
> --Todd
Man, you *really* need to cut down on the coffee ;-)
--
Tony Priestman
|
|
| |
In lugnet.admin.general, Larry Pieniazek <lar@voyager.net> writes:
> Do we REALLY need the precision that seconds bring us? :-)
>
> I'd vote for days or at least hours.
"Admiral, if we go by the book, like Lietennant Saavik, hours would seem
like days."[1]
> Even for a non human readable API like this one, go with data that's
> understandable to humans and let the machines keep the books straight.
Days are certainly human-readable and intuitive and okie-fine for relative
times expressed counting backward from "now," but what about absolute times?
What if you wanted to restrict a search between April 1, 1999 and April 7,
1999 inclusive?
Seconds since Days since
Time/Date stamp the epoch the epoch
-------------------------- ------------ --------------
April 1, 1999 00:00:00 GMT 922924800 10682
April 7, 1999 12:59:59 GMT 923529599 10688.99998843
April 8, 1999 00:00:00 GMT 923529600 10689
If the range is given as [a,b), then whole number days work fine. If the
range is given as [a,b], then fractional days like 10688.99998843 would be
needed. Or if you wanted to search from 6:00am to 6:00pm on some day, then
you'd also need fractional days.
In any case, is a number like 10682 really any more meaningful than
922924800? Sure, it's shorter...but that actually makes it more confusing
because it looks like something that's supposed to make sense but doesn't.
At least 922924800 doesn't look like it's supposed to make sense.
--Todd
[1] STII:TWOK ;-)
|
|
| |
In lugnet.admin.general, Todd Lehman writes:
> [much useful stuff deleted]
> How about qt= for
> the target time and qs= for the sigma (provided that some other non-greek
> mnemonic can be identified for 's'):
How about a non-GEEK mnemonic? Oh, sorry, I forgot who I'm talking with (-:
> [much more deleted, including an intensely elaborate and feindishly clever way
for the server to talk to itself via HTTP EQUIV reload directives -- whew!]
- Robert
|
|
| |
In lugnet.admin.general, Todd Lehman writes:
> STII:TWOK
Just the sound that was made as I released the bow string and the arrow dug
itself into the concrete wall behind the target...
Cheers,
- jsproat
|
|
| |
In lugnet.admin.general, Sproaticus <jsproat@io.com> writes:
> Sure, sounds okay. I'm a little nervous about handling raw seconds; the big
> numbers make my puny earthling brain hurt. :-, How about using the same
> syntax used in the traffic report page; e.g.
>
> http://www.lugnet.com/news/traffic/custom.cgi?hours=6
>
> Shows what's happened in the past 6 hours. How about something like
>
> http://www.lugnet.com/?q=jeremy+sproat&qtmonths=6&qsdays=7
>
> to ask for the results to prefer articles submitted a month ago, with s
> spread of 7 days?
Apart from the URLs getting longer and more clutterred with parameters and
being harder to share via cut & paste into messages, it would probably also
mean two separate URL interpretation mechanisms (more code bloat, even if
it's broken into a separate library) rather than just one which converts
human time to epoch time along with everything else and feeds the result to
a lower layer.
BTW, how would you write the following range using the multi-parameter
approach?--
From: 31 Dec 1998 23:45:00 EST
to: 1 Jan 1999 00:30:00 EST
(Let's say you're looking for Happy New Year messages posted by people in
the New York City time zone last year.)
http://www.lugnet.com/loc/us/ny/?q=happy+new+year&........
What goes in the ....'s ?
> Hmmm... There would be lost flexibility then, as you can
> only ask for integral values of one time metric. Arg. I'll have to
> surrender to the intellectual superiority of my browser. :-P
Well, not necessarily; they could be floating point just as easily as they
could be integer (not that I don't still prefer seconds).
They numbers on the custom traffic report page are non-integer, for example:
http://www.lugnet.com/news/traffic/custom.cgi?hours=.5
http://www.lugnet.com/news/traffic/custom.cgi?hours=1.5&days=2.33333
--Todd
|
|
| |
In lugnet.off-topic.fun, "Robert Munafo" <munafo@NOgcctech.SPAMcom> writes:
> In lugnet.admin.general, Todd Lehman writes:
> > [much useful stuff deleted]
> > How about qt= for
> > the target time and qs= for the sigma (provided that some other non-greek
> > mnemonic can be identified for 's'):
>
> How about a non-GEEK mnemonic? Oh, sorry, I forgot who I'm talking with (-:
LOL! Yes! :) It shouldda said non-g[r]eek or non-gr?eek then, eh? :-)
> > [much more deleted, including an intensely elaborate and feindishly clever
> > way for the server to talk to itself via HTTP EQUIV reload directives --
> > whew!]
Oh, not via the <META HTTP-EQUIV=...> directive, but via the 'Location:'
header right in the HTTP response. You can see an example of this in action
(sans a complex HTML form) if you try to pull up an old article URL:
http://www.lugnet.com/news/display.cgi?lugnet.off-topic.fun:2696
Note that it automatically redirects this (via the 'Location:' response) to
the new URL:
http://www.lugnet.com/off-topic/fun/?n=2696
without having to mess with sending back an intermediate HTML document.
--Todd
|
|
|
