>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.
>
>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.
Well I know you're in the middle of this and now is probably not the time
to change courses, but I highly encourage you to switch to XML-RPC instead,
or to take a look at my proposal (at http://www.theashergroup.com/demos)
and design with something like that in mind. Eventually, the choice of
CORBA or XML-RPC protocols should be a trivial no brainer that you delegate
to a higher level "get me a remote service layer", but the advantage of
XML-RPC over CORBA now is that you'd get your data back in a structured
manner, very JavaScript friendly, and you'd be opening your site/service up
to partners in a relatatively easy to implement manner.
Jerry
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/htdig-dev
