Add a pending object which maintains the pending toolcallid wrt
each chat session, when ever a tool call is made.
In turn when ever a tool call response is got cross check if its
toolcallid matches that in the pending list. If so accept the
tool call response and remove from pending list. If not just
ignore the response.
NOTE: The current implementation supports only 1 pending tool call
at any time.
NOTE: Had to change from a anonymous to arrow function so as to
be able to get access to the ToolsManager instance (this) from
within the function. ie make use of lexical binding semantic of
arrow functions.
Me.tools.toolNames is now directly updated by init of ToolsManager
The two then in the old tools.init was also unneeded then also as
both could have been merged into a single then, even then. However
with the new flow, the 1st then is no longer required.
Also now the direct calling of onmessage handler on the main thread
side wrt immidiate result from tool call is delayed for a cycling
through the events loop, by using a setTimeout.
No longer expose the tools module throught documents, given that
the tools module mainly contains ToolsManager, whose only instance
is available through the global gMe.
Move the devel related exposing throught document object into a
function of its own.
Rename Tools to ToolsManager to convey its semantic better.
Move setup of workers onmessage callback as well as directly passing
result to these callbacks into ToolsManager.
Now that Workers have been moved into ToolsManager, and ToolsManager
has been instantiated as a member of Me, use the same in place of
prev workers of Me.
So that all tools related management logic sits in tools module
itself, but is accessible from Me by having a instance of Tools.
The Workers moved into Tools class.
The tc_switch moved into Tools class.
The setup_workers, init, meta and tool_call moved into Tools class.
Given that Me is now passed to the tools logic during setup, have
the web worker handles in Me itself, instead of in tool related
modules.
Move setup of web worker related main thread callbacks, as well as
posting messages directly to these main thread callbacks, into Me.
Update the descriptions of set and get to indicate the possible
corner cases or rather semantic in such situations.
Update the readme also a bit. The auto save and restore mentioned
has nothing to do with the new data store mechanism.
In the eagerness of initial skeleton, had forgotten that the
root/generic tool call router takes care of parsing the json string
into a object, before calling the tool call, so no need to try
parse again. Fixed the same.
Hadnt converted the object based response from data store related
calls in the db web worker, into json string before passing to the
generic tool response callback, fixed the same.
- Rather the though of making the ChatMsgEx.createAllInOne handle
string or object set aside for now, to keep things simple and
consistant to the greatest extent possible across different flows.
And good news - flow is working atleast for the overall happy path
Need to check what corner cases are lurking like calling set on
same key more than once, seemed to have some flow oddity, which I
need to check later.
Also maybe change the field name to value from data in the response
to get, to match the field name convention of set. GPT-OSS is fine
with it. But worst case micro / nano / pico models may trip up, in
worst case, so better to keep things consistent.
Pass chatId to tool call, and use chatId in got tool call resp,
to decide as to to which chat session the async tool call resp
belongs and inturn if auto submit timer should be started if auto
is enabled.
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.
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
Had forgotten to specify type as module wrt web worker, in order
to allow it to import the toolsconsole module.
Had forgotten to maintain the id of the timeout handler, which is
needed to clear/stop the timeout handler from triggering, if tool
call response is got well in time.
As I am currently reverting the console redirection at end of
handling a tool call code in the web worker message handler, I
need to setup the redirection each time. Also I had forgotten
to clear the console.log capture data space, before a new tool
call code is executed, this is also fixed by this change.
TODO: Need to abort the tool call code execution in the web worker
if possible in future, if the client / browser side times out
waiting for tool call response, ie if the tool call code is taking
up too much time.
tools manager/module
* setup the web worker that will help execute the tool call related
codes in a js environment that is isolated from the browsers main
js environment
* pass the web worker to the tool call providers, for them to use
* dont wait for the result from the tool call, as it will be got
later asynchronously through a message
* allow users of the tools manager to register a call back, which
will be called when ever a message is got from the web worker
containing response wrt previously requested tool call execution.
simplechat
* decouple toolcall response handling and toolcall requesting logic
* setup a timeout to take back control if tool call takes up too
much time. Inturn help alert the ai model, that the tool call
took up too much time and so was aborted, by placing a approriate
tagged tool response into user query area.
* register a call back that will be called when response is got
asynchronously wrt anye requested tool calls.
In turn take care of updating the user query area with response
got wrt the tool call, along with tool response tag around 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.
Move tool calling logic into tools module.
Try trap async promise failures by awaiting results of tool calling
and putting full thing in an outer try catch. Have forgotten the
nitty gritties of JS flow, this might help, need to check.
Checks for toolname to be defined or not in the GenAi's response
If toolname is set, then check if a corresponding tool/func exists,
and if so call the same by passing it the GenAi provided toolargs
as a object.
Inturn the text generated by the tool/func is captured and put
into the user input entry text box, with tool_response tag around
it.
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