services/drivers/plugins managers..don't we foget the most important thing in all this?

I believe whole heartedly in the concepts stated above. Our plans to have plugins install dynamicaly and automatically require that we create an abstract UI that does not require the user to know what is installed. The above suggestion that we use a natural human language it a good foundation. In this disscussion are found some problems with that idea as a whole.

One of the problems I have found with it, is the existance of a local database of possible actions to invoke against an object. This db either would not reflect the development of new actions, or would have to synchronize with an external source that would.

This is my suggestion, only an ammendment to the above idea. The local system could maintain a list of commands mapped to actions. The commands would be Strings of any form. The language of the Strings could be that of the user or just symbles the user made up. '(>?' The commands would take the form of plugin URI's which will be actionable with the plugin manager. The URI's specify what class to use and what args to supply (String[] for main).

This is then a list of the default actions for a set of commands.

It was suggested above that a text field be the start of user interaction. I will use that idea. The user would type in that field a command that he would use. The system both looks for a local match in the command/action map, and sends a multicast signal to other systems. Recieving systems would then respond with their default action for that command, if there is any. These resoponces would be collated (graphically for intrest) in order of the number of votes from remote systems (how many agreeing responces it got).

These actions, and the local default action would be show to the user graphically (after some formating). The user could then base his desicion either on the popularity of the plugin (number of votes) or specifically by the name of the plugin. What ever he chooses would become the new defalt actoin for that command.

In this way, logical commands stated in natural languages, would be easily found. Most people would say: Edit document or Redacta documento or Dokument redigieren. But also the user could create 'hot keys' for programs that he uses often.

What do you think?

Alex

If I correctly understood your approach you want to map textual commands to actions at runtime and also create the gui dynamically using these actions. I hope I understood it, at least the main characteristics.

Maybe we can make it even more abstract. As Alex already pointed out in his comment, the command to action mappings will have to be localized. So what is the solution to this? Simply make the system understand the commands, so it can translate them between different languages.

Ok this makes it even more difficult to implement. But I think this is what we really want. Also the system must be able to understand the commands to be able to incorporate context. I.e. if I'm reading an email from Susan (she's asking whether I will attend her birthday party) and two hours later I tell the system 'Tell Susan I will attend her birthday party', the system will use the context (birthday party) to figure out to which of the three Susans I know to send the email reply to. Of course this is also some kind of presumption and hence errors raised by misinterpretations might arise, just as happens to humans.

Of course I didn't show a way to 'know' that both statements 'Please wash my car.' and 'My auto needs a wash.' will lead the speaker or hearer to wash the car. I simply don't know how to do it, yet.

Another issue is, how to translate a natural-language statement like 'Tell Susan that I will attend her birthday party.' into bytecodes / actions. I.e. I imagine some graph-based system, that will analyze the sentence and see, that 'tell ... that ...' is an action (e.g. send an email), 'Susan' is a person acting as the recipient of the email, which is a parameter to the 'tell ... that ...' action. 'I will attend her birthday party' is the contents of the message (i.e. the second parameter of the 'tell ... that ...' action.

I think it might be possible to create a layered model of computer instructions, whereas each layer adds more abstraction / reliance on context. It will be possible to transform elements from layers to elements of higher (abstraction) or lower (compilation) layers. This is also necessary, because lower layer actions / commands will be more efficient to process.
-------------------------------------
Layer 2: Natural language commands
-------------------------------------
Layer 1: Action classes
-------------------------------------
Layer 0: Java Bytecode / Machine code
-------------------------------------

If you don't see what I mean, please don't mind about my state of mind . I just wanted to check whether anyone else is thinking about something similar. I will try to do some experiments to clarify this stuff to myself and maybe I will then be able to explain it more conceptional.

Regards

Sebastian

I have had this dream before. Your sollution is very interesting; and not disimilar to one that I had. Most of your idea is better than mine, but some I need to question. Forgive me if my logic doesn't flow smoothly.

I like the idea of texturally requesting a service by function. The main reason is because it could work over the peer network I am developing. If a system got a strange request like 'Document Convert To Spanish' The system would search for it locally but probably would not find it. Then the system could send a multicast datagram with the requst in it. Other systems would recive the request and try to fill it. Any one that could fill it would respond with the class name and version of the class that matches the request. The originating system would then lookup that classname and version, which results in the download and install of the service. Then the request would be tried again, and the sollution would be found.

Unfortunatly there seems to be a major problem with the text protocal. Internationalization. Would every service be required to describe itself in every language? Or should we do like java has and impose the text protocal as engish only (with German gramer:)?

Another difference between your plan and mine is that I would have let the services controle the gui. Your plan is of course much more interesting. Do you think it is really possible? Specifying parramiters could be done by the constructors. An email app would need a URI[] for to, a URI for from, String subject, String body, and byte[][] attachments. The byte[][] could be a File[] but I would like to get away from the traditional idea of a file (ask me some time

Any way would the GUI system be able to generate the apropriat fields, place them in a layout that wasent misshapen or unusable, and validate the input (turn a String into a URI)?

I would love to see this work becaue it would add a consistent and unique look to jnode. Another good thing about this is that it abstracts the view from the model. Add to this a reliable persistence mechanism like JnodeFS, and we have the much aclaimed three tier application.

One of the realy wonderful things that should come with the abstraction of view and model is that we should be able to switch the model without loosing the data in the view. For example. A user uses a Document Edit model to write a text document. He should then be able to switch to a Document Spell-Check and spell check, then a Document Email, and send the document. This should happen without re-typeing the note, or opening it from harddrive.

This ability it not natively apparent in your system because each peice of the GUI is generated dynamically. Alow me to sugest this idea. That the user interaction does not start with just a text field and a combo box, but also a central component.

Ever application you use revolves around one important component. A text editor ueses JTextPane, a spreadsheet uses a JTable, a calculator uses a JTextField, a playlist uses a JList, and a paint program uses a Canvas. This list of key components does not excede eight or nine members.

If these few componets were displaid (as icons) along the top of the desktop, the user could select the one that he needs to use depending upon what he wants to do. This selection also gives us more specific model search capablities. The important idea here is that the central component (say a JTextPane) would stay inplace (and retain its internal data) as the model is switched arround it. This would allow the user to write a note, spellcheck it, save it, and email it, very easily from one frame.

There are still more issues to consider, but I will take a break now and let someone else have a chance.

Let me know what you think.

Alex