Ok I see your point...really what I'm after here is keeping the existing
functionality with template/map type output but separate the meat of the
search from the display logic allowing a developer to display the results in
any fashion they would like to imlement.
Now Geoff has mentioned a framework idea, which is a VERY good idea. I have
been working for an e-commerce company for the last year and a half, one of
the biggest things they have stressed in development of pages is to separate
all your work from your display logic. This gives you the benefit of being
able to easily debug display type problems and being able to have clean exit
routes instead of loading a buffer with partial data and then having to
abort due to an exception in the processing to display. An example of this
would be having htsearch return a set of results and in the middle of
writing the results out have some form of exception that causes processing
to abort. The client running htsearch would get back partial results and an
error at the end of the page lets say.
I'll try and squeeze some time in on this at somepoint soon but as things
are a bit tight with my schedule I don't believe I'll be able to do it.
My work to access the htdig search facilities through CORBA is to allow my
company's software, which has it's own front end processing facility and
session management architecture, is to get the results back in a flat format
and then use the front end processing to format the results as needed (it's
based on JavaScript pages) and add session management entries to the URLs.
----- Original Message -----
From: "Jerry Asher" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 20, 2001 13:44
Subject: Re: [htdig-dev] XML-RPC and htdig (was Idea on display system)
>
> > > It appears to work pretty well, but it would be nice to see a bit more
> > > structured support of this, although, to be frank, I am not sure what
that
> > > would look like. Although I do know one thing I would like, and that
is
> > > more of a programmatic API and linkable library into htsearch, not
just a
> >
> >Many people have mentioned this--it's certainly a good idea. I imagine as
> >a 3.2 release firms up, the class interfaces can be finalized. But
> >feedback is certainly welcome as to "what it would look like."
>
> Hmm. I'm not sure if you are agreeing that support to separate logic from
> display is a good idea, or a programmable interface. Assuming the latter
...
>
> I compared SWISH-E, SWISH++, and htDig about two months back. I
eventually
> implemented htdig as I like htDig's support for excerpting. But I
> remember thinking that the SWISH "family" had better programming APIs
> (although most has reputations for being pretty buggy.)
>
> I think a library I would like to see would have interfaces that let me:
>
> 1. get a handle to a index
> 2. specify a search and get a handle to search results back
> 3. obtain next <n> results (where n is a parameter, and
> you loop until no more results or until you close the search handle
> 4. close search handle
> 5. close index handle
>
> Regarding 3, I can imagine that the output is either/both
> a. A list of strings (following the long/brief/... template) that
describe
> the e next n results
> b. a list of specific result handles that you then have another interface
> that lets you get information back about that result
> resultInformation *htSearchOneResult(handle)
>
> I am lisp, tcl and xml biased, but I would suggest not creating these
> things to take or return complex C++ structs, but to take/return arrays or
> lists of simple string based descriptors (and simple xml descriptions
would
> be wonderful.) The goal would be to make it trivial to create efficient
> interfaces to the htSearch library in C, C++, C#, perl, Tcl, Python, Java,
> whatever...)
>
> Regarding specification of display and results, I guess I am pretty happy
> with the template_map mechanism, although I do think it would be good just
> to natively support an XML description as well.
>
> I am willing to help out, within my time constraints, and within my
> ignorance of C++ and htdig internals....
>
> Thanks,
>
> Jerry
>
>
>
>
>
> _______________________________________________
> htdig-dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/htdig-dev
>
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/htdig-dev
