NOTE: not a robust check, just tries to establish a http connection
for now and doesnt really check if it is the specific proxy srvr
of interest or not.
So that the same error path is used for logical error wrt http req
also, without needing a different path for it.
Dont forget to return the resp text/json/..., so that the contents
are passed along the promise then chain
Ensures that if the url being requested as any query strings in
them then things dont get messed up, when the url to get inc its
query is extracted from the proxy request's query string
Use HTMLElement's dataset to maintain tool call id along with
the element which maintains the toolname.
Pass it along to the tools manager and inturn the actual tool
calls and through them to the web worker handling the tool call
related code and inturn returning it back as part of the obj
which is used to return the tool call result.
Embed the tool call id, function name and function result into
the content field of chat message in terms of a xml structure
Also make use of tool role to send back the tool call result.
Do note that currently the id, name and content are all embedded
into the content field of the tool role message sent to the
ai engine on the server.
NOTE: Use the user query entry area for showing tool call result
in the above mentioned xml form, as well as for user to enter
their own queries. Based on presence of the xml format data at
beginning the logic will treat it has a tool result and if not
then as a normal user query.
The css has been updated to help show tool results/msgs in a
lightyellow background
These no longer need to worry about
* setting up the console.log related redirection to capture
the generated outputs, nor about
* setting up a dynamic function for executing the needed
tool call related code
The web worker setup to help run tool calls in a relatively
isolated environment independent of the main browser env,
takes care of these.
One needs to only worry about getting the handle to the
web worker to use and inturn pass the need code wrt the
tool call to it.
So that when tool handler writes the result to the tc_switch, it
can make use of the same, to write to the right location.
NOTE: This also fixes the issue with I forgetting to rename the
key in js_run wrt writing of result.
As output generated by any tool/function call is currently placed
into the TextArea provided for End user (for their queries), bcas
the GenAi (engine/LLM) may be expecting the tool response to be
sent as a user role data with tool_response tag surrounding the
results from the tool call. So also now at the end of submit btn
click handling, the end user input text area is not cleared, if
there was a tool call handled, for above reasons.
Also given that running a simple arithmatic expression in itself
doesnt generate any output, so wrap them in a console.log, to
help capture the result using the console.log trapping flow that
is already setup.
The implementations of javascript and simple_calculator now use
provided helpers to trap console.log messages when they execute
the code / expression provided by GenAi and inturn store the
captured log messages in the newly added result key in tc_switch
This should help trap the output generated by the provided code
or expression as the case maybe and inturn return the same to the
GenAi, for its further processing.
Define the meta that needs to be passed to the GenAi Engine.
Define the logic that implements the tool call, if called.
Implement the flow/structure such that a single tool calls
implementation file can define multiple tool calls.
hanishkvc