Ensure toolNames array is reset, each time setup is called, so
that it doesnt end up with duplicate entries and equally dont
end up with entries of tool calls which are no longer available,
maybe because some config changed etal.
Ensure the ChatId is logged wrt the toolweb related setup actions.
Ensure that ExternalAi tool call related chat session, has its
tools config disabled, when its created itself, so that end user
doesnt get confused, given that external_ai toolcall explicitly
forces tools support to disabled.
Update some of the notes and readme
Split init from setup wrt Tools. Init is called when the program
is started, while setup is called when ever a session is created
and or when ever any tools setup related config is changed (like
proxyUrl getting modified or so).
This allows one to modify tool related config and inturn update
the tools related states wrt same (like wrt the proxyUrl, bcas
the simpleproxy server will change, one needs to cross check which
and all web services are available with the new simpleproxy server
and so and so ...)
To help with the above, now ToolsManager maintains multiple tool
call switches, where there will be a tc_switch wrt each chat
session.
All tool related codes, where needed have been updated to work
with the chat session for which they have been called, instead
of any global states.
In future, this can enable one to allow user to enable or disable
the tool calls exposed in each of the chat sessions,
This immidiately needed toolweb and toolai to account for chat
session as needed.
In future, if we want to keep the data store isolated across
chat sessions, then this can be useful, in that it can create
uniq store names for each of the chat sessions, isntead of
sharing a common store name across all sessions.
The chat session creation as well as tool init/setup related
flows have been updated to chain through or account for the
promises as needed
Update the external ai tool call description to indicate that it
doesnt have access to internet or tool calls.
Update the sys_date_time description and avoid the confusion caused
to some ai wrt the template string as to whether it is optional or
required and wasting reasoning time around it. Now simply state that
it is a reqd argument, and suggest the internal default template as
a useful one to use.
Update the msg returned by data store tool calls, to make them less
verbose (ie avoid duplicating key list or got key data) while also
more informative (ie num of keys, data length)
Update the readme.
Avoid chat_show getting called twice during starting.
Update description of sys_date_time to be more verbose
Update the readme DONE section, where I had few days back forgotten
and started making entries as parts of a item list or so.
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.
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.
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