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 SimpleChat to have a duplicated instance of Config instead
of a reference to the global Me instance.
Most logics updated to work with the config entries corresponding
to the current chat session.
ShowSettings, ShowInfo and getting current sliding window size in
user friendly textual form have been moved to Config from Me.
ALERT: With this now, user clicking settings will be able to modify
only the settings corresponding to current in focus chat session.
TODO:
ToolsMgr related use within SimpleChat and beyond needs to be thought
through and updated as needed.
Should tools.proxyUrl be unique to each SimpleChat or ...
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.
Include the DivStream of ExternalAi toolcall in the other chat
session UIs, so that user can see what the external_ai toolcall
is doing, without having to switch out to external ai session tab.
Update the name of the tool call external ai session.
Ensure to clear previous chat session wrt external ai tool calls
As the ai may call external ai toolcall with the same system
prompt sometimes, which wont trigger the autoclear logic, wrt
the corresponding chat session.
TODO: In future maybe provide a option to continue any previous
chat session if the system prompt is not changed wrt external ai
toolcall.
This will help ensure that switching sessions etal wont lead to
loosing handle to sessions that one exited from, with additional
logic to be added later.
Rather I am thinking, maybe it may make more sense to dynamically
pick the currently active chat sessions latestResponse field to
inturn show into a div element at end of the elDivChat.
On thinking further, maybe making elDivStream into elDivStreams
with seperate div for each session is the better thing, as the
SC.handle_response will be able to update its corresponding div
and the session switch can link the currently visible session's
div to be mapped to elDivChat.
NOTE: Rather this commit in itself should take care of the current
normal flow, which wont allow user to switch sessions when a tool
call or handshake with server is pending. However in future if
I want the ui to be freely switched independent of if a tool call
or server handshake is active, then I need the logic mentioned in
previous para.
Had a custom struct for parts of Me needed by SimpleChat, and inturn
that need to be controlled when starting a independent parallel ai
session. For now if chat streaming is used or not and tools is enabled
or not is allowed to be explicitly controlled when handle_chat_hs is
called.
Inturn when toolai triggers the parallel ai session, it disables
tools calling support wrt this child/external ai tool call. Else
even the external ai session may end up triggering tool call wrt
external ai for the same job and thus get into a infinite recursive
loop.
Also
* update the toolai meta data a bit.
* increase time allowed for toolcall to return a response, especially
usefull for external_ai tool call.
Cleanup some old notes and update readme in general.
hanishkvc