Discussion of command history in desktops

[Stefan Israelsson Tampe]

Hi,

I'm looking for a project to spend some of my spare time on. And wonder
if you find the following proposal interesting. If we find it worth
studying this forum looks like a good place to start discussing it.

Abstractly when I work with gui application what I most often do is
constructing arguments to be executed by a function e.g. 

	>myapp/.../set_color object rgb-color

Now, I find the backward-search in the command history very useful in a
lot of applications I use (shell,matlab,python,...) 

Question:

	Is a "command history" on the desktop level of any use e.g. do 	we want
to design a protocol to direct textual representation of 	application
commands to a global history server for usage such as 	simple backward
search or to do more complex searches. Or do 
	just introduce bloat?


Remarks:
	*Gui - applications generally do not work with textual 	representations
of commands and do not expose these to the user.
	so it is harder to search. But note that a search for an IP 	adress
entered last week can still yield useful results.
	
	*The recent file history is a kind of example of such an 	application
so we do use these ideas today, is it worth to 	generalize this?.

 	*I think that this sort feature facilitates a Input Once 	paradigm.

	*The input from humans are slow, so we should not stumble upon 	any
performance issues at first glance, we risk of cause on the 	other hand
bloating applications.
	
	*The recall command, modify and run use case could of cause be
	facilitated.

	*We should make sure that running in user mode and running in 	program
mode is tracked to ensure that scripts do not send command
	representations to the history.	

	*Writing metadata to be associated with a user input is more 	likely to
be done and is more effective (one program is used by 
	many users) then associate metadata to a file, so recalling a 	file by
associating with what I did with it seems to be an
	interesting approach. 
		
		eg. find file associated with MIME svg and associates 		with mouth
sometimes during the previous 30 days
	
		-Remark, 	going through all svg-files during the
				last 30days and in those search for 				mouth is another approach of
cause.

	*Find previous enered settings in a form is simple. by
 	not storing previous steps in the document is good I think.
	if you need to bring the history with you bring it in an extra 	file
and import the history to your new desktop. 	

	*If I make one command per minute which say consists of 100 	bytes and
work for 8 hours I will generate about 1 megabyte of 
	data per month, searching one megabyte backwards for a match is 	done
in less then 1/10 of a second I think.
	
Implementation.
	*How do we connect the application to the server. I might want
	many servers picking up the commands. 
		
	*Using Dbus

	*Thinking about the form of the message about the command 	string I
suggest the following,
	message = (item_1,item_2,...,item_n)
	item_k = ("argname" , "valuetype", "value")

	eg.
	(
		("date" 	"date/se" 	"2004-09-20") 
		("fkn" 		"path" 		"/myapp/.../set_color")
		("data"		"file"		"~/smile.svg")
		("arg/item"	"text"		"mouth")
		("arg/color"	"color/rgb"  	"128,0,0")
	)

	*We need to specify value types and some meta data argument 	names as
well

	*It is good to unify the textual representation of a value e.g.
	rgb-color, date,time but actually one can think of reasons to 	not
specify these too strictly e.g. less burden on application 
	writers implying harder to search and use data though. 

	*I'm not an expert in databases, but implementing a simple 	backward
search server a can do, I actually made one in python
	using the dbus a couple of days ago, but for performance reasons
	I think that a c-version with python interfaces is something I 	could
start hack on.
 
	*It would be nice to try implement the client side, on a
	live application and test it out, any suggestions.


Regards
Stefan