Programming Language Neutral Gui
Some (mostly) language-neutral GUI engines, although the language-neutrality is always within constraints:
- MozillaXul + XpCom (Used by Mozilla and the Gecko rendering engine)
- UNO (Used by OpenOffice.org)
- COM/ActiveX (Used in many Microsoft products, famously in VB)
- Avalon, once released? Accessible via any .NET language
- XForms, while not really a "GUI engine" as I would use the term, seems to provide what Top is looking for on this page.
- TIBCO General Interface (http://www.tibco.com/devnet/gi/default.jsp)
EditHint: Merge or move this list to RemoteGuiProtocols? Plus, the list does not belong at the top in my opinion.
Desired features:
- Language neutral - Easy to port API's and/or use markup with many different languages
- HTTP-friendly - Usable over HTTP and reasonably latency-friendly, such as not requiring each key-stroke to travel both ways before a character appears, as found on HTML forms.
- Minimal reliance on client-side scripting or execution, but still has such ability if desired.
-
Targets mostly business CrudScreens, since the existing standards are fairly good for e-brochures.
- Top clearly has an agenda. I'd want something good enough for distributed videogaming, so I could put everything from CrudScreens to full-blown map-based applications and tele & videoconferencing on it. I.e. an InteractiveSceneGraph language, and an associated browser.
- You have a video-gaming agenda.
-
Incorrect. I have a "low-latency distributed-system updates plus 3D and audio and new input devices beyond the limited keyboard+mouse" agenda. This requires design towards optimization and caching support as well as some very flexible and mutable scenegraphs. It just happens that targeting distributed videogames gives me everything I want: any solution "good enough for distributed videogaming" will handle everything else by necessity.
- I disagree. Biz-friendly widgets are hard to get right. A gaming company wouldn't have any motivation to do them right. Making prettier explosions and sparkling blood is not going to help get a decent TableBrowser.
- I'm not asking a gaming company to create a ProgrammingLanguageNeutralGui and you aren't asking businesses to do it either - you've tossed the idea to the open community for a reason. And Biz-friendly widgets aren't especially difficult; video-gaming systems that provide interactive HeadsUpDisplays (meaning most of them) invent such things repeatedly. Such things are used for a variety of purposes, including inventory management and status summaries. There is much more to videogames than prettier explosions and sparkling blood.
- Anyhow, let's agree that we need better GUI and graphics standards for many different uses. Biz use is one of many.
- Certainly.
- Java applets should be good enough for teleconferencing because the interaction is limited once started.
- And Javascript+AJAX+HTML should be good enough for your CrudScreens. That doesn't make these into satisfactory solutions.
- So far they are not good enough. If they someday prove good enough, this may change.
- Open standard
- Include an event-handling vector language (nice to have, but not a requirement). This could also be used to add custom features not part of the standard widget set.
Open Issues
- What measurable benefits, if any, would 'programming language neutrality' presumably offer?
- How is neutrality measured or qualified? What constraints on the GUI language is implied by 'programming language neutrality'?
- Can it be done, or to what degree?
- Compared to known alternatives, how do the alleged advantages of 'neutrality' stack up? Is it worth doing?
-
How likely would it be to have something like JavaScript and plugin-objects hacked in atop of it, thus defeating the 'neutrality' concept? How often would these be used?
- Please clarify "hacked in". Ideally, and orderly approach to interacting with app languages would be devised. If many feel a need to "hack" lots of back-door links and intrusions into the guts, it may be a symptom that some feature or interface is lacking.
- By 'hacked in' I mean that they aren't designed into the system in such a manner that they interact in an orderly manner with all elements processing the language (e.g. if javascript and plugins were "designed in", then CascadingStyleSheets would influence them, too). I agree that hacking in links is a symptom of missing features (MissingFeatureSmell). The question, though, is whether the "missing features" can be fixed in combination with 'declarative' and 'language neutral', or while maintaining a distinction between 'GUI language' and 'app language'.
- Will it use API's or a markup language or an InteractiveSceneGraph language or something else?
- How to handle CoordinateVersusNestedGui - Support both kinds? What about ZoomableUserInterface?
-
How to handle real-time updates
- such as how often or when to refresh?
- Polling is one option, but is a very inefficient option in terms of both performance cost (bandwidth, message counts) and final performance (latency between update and seeing it). That is, it is the most expensive and worst performing of the practical options. Subscriptions and events are a better choice for both performance cost and performance, but are more complex for implementation. Thus, the question is different than 'how often to refresh'; it really is 'how to handle real-time updates'.
- For most actions, a refresh is only needed when a button or menu is pressed (if designated to wait for it), which would probably be a typical POST transaction in HTTP. Polling may be sufficient for the rest of the cases. I envision that a given event, such as "on-click", is designated either "wait" or "no wait" at the client side. "Wait" means it waits for a response from the server (hour-glass) until it receives a response, which may contain a REFRESH command.
- I must strongly disagree. It would be far more ideal to be able to, say, see updates to WikiWiki and CRUD-screens and forums in real-time as other people interact with the resources each document represents. And that's even before we're working with more interactive GUIs. Are you imagining a world where the user is the major source of updates that are useful to observe? Sorry, but that world died shortly after the Internet was born.
- How to handle enough separation of content and presentation to support non-standard output devices (e.g. small mobile phones, screen readers for the blind) and styles (some equivalent to CascadingStyleSheets).
- How or if it can take advantages of particular app language features.
(Similar lists are given below. This topic needs a refactoring.)
This page is mostly Top arguing with people again.
I am just trying to collect ideas, definitions, etc. about the concept. I did not mean to start arguments. I find it an interesting topic to ponder. Many GUI's seem too tied to languages, and I wonder if that is an inherent need, or bad industry habit. If you don't find the topic interesting, then simply don't read it or contribute. Generally, arguments are a sign that the topic needs further exploring, clarification, etc. Whether you like my content style or not, you have to agree that the topic is an area left wide open so far. -- top
It'd be nice if when you collected ideas and definitions you paid more than passing interest to what other people were saying, then. The topic is NOT an area left wide open - the way you phrased it and named it made it an oxymoron to begin with. The argument here was not one over the fundamentals of GUIs, but with you and your redefinition of/misuse of terms. There is no such thing as "Language neutral GUI engine". There is no such thing as a language neutral engine at all. Computers just don't work like that. You *must* have a common protocol for calling into each other, which *always* requires explicit support at both ends of the channel. Happily, there is a de facto standard calling convention, which is C. What you seem to want is a standardized GUI declarative language. This is fine if your needs are limited to the functionality provided by whoever designed your markup language. HTML is an excellent example - you can extend it via DHTML. But you can't implement DHTML in any language you want - you must implement it using one of the languages supported in the browser. And the browser must explicitly support and allow you to do so. This is not language neutrality!
First off, I am not proposing (only) a markup language. The interaction would be an important part of it. Second, as described below, '"language neutral" is probably not a Boolean concept, but that is not a reason to not try to reduce dependence.' Nor do I think C bindings are necessarily the way to go, since one cannot easily bind across HTTP, for example. But if you can show it absolutely necessary, then we've learned something. By the way, which alleged definition are you bothered by? I do agree that we may need to create some working definitions to avoid confusion.
You cannot have an interactive environment and still maintain anything resembling "language neutrality". What part of this is so hard to understand? Spend a few minutes thinking about ways to implement the concepts you're thinking of and you'll see what I'm talking about. By the way, it's pretty trivial to wrap C function calls in SOAP and tunnel them over HTTP. It can even be mostly automated. Of course, the same applies for pretty much any RPC wrapper. And, as a defacto standard, a C API is as close as you can get to "language neutrality". The term is still ridiculous, but I'll assume it means "accessible as easily as possible from the most languages".
If you have specifics of how to do it right or proof that it cannot be done, then please present those specifics. Your criticisms are not specific enough for me to use or to change my responses with. I will happily fix my suggestions if you provide the proper details. I've been thinking about language-neutral HTTP-friendly GUI approaches since about 1996 and have mentally tested my ideas on the various projects I worked on since that time. True, that's not as good as a live test, but DontComplainWithoutAlternatives. The point is that I reject your claim that I've not thought about it carefully enough. You have yet to point out a *specific* flaw that is not fixable. -- top
The *specific* flaw that is not fixable: the 'neutral' is impossible. Even mostly declarative 'markup' languages like HTML require considerable framework to be used from any given language or platform. Further, existing GUI languages have repeatedly proven to be insufficient for interactive designs - a fact that observed by examining the need for plugins, hacking in scripting languages, etc.
An alternative: take the exact opposite approach. Create a rich language that supports mobilizing code to reduce latencies and improve interactivity and specialize caching to the domain. Instead of shunning rich language features because their implementation isn't friendly to a given language, accept that you'll be implementing and porting frameworks across the common platforms and languages. With the 'neutrality' constraint released, focus on LiberatingConstraints more useful to achieving rich user interfaces. Such constraints include capability security to allow rich mashups without loss of privacy, distributed transactions to allow composition of remote services without race-conditions, separation of content and presentation to support the handicapped, requiring ZoomableUserInterface with level-of-detail to reduce bandwidth consumed by objects not under immediate attention, demanding termination guarantees and confinement and type-safety for certain classes of operations in order to allow a variety of optimizations, and in general support minimal-latency real-time updates to observed objects as other users interact with them.
The cost of this alternative is that it is slightly even more unfriendly to one-off implementations compared to, say, one-off HTML processor that neither reads nor introduces and blocks.
To answer this cost, one implements and ports a framework and the associated protocols to the different platforms and languages that demand it.
That, to me, is a fully acceptable payment for a richer GUI.
[context missing due to unknown change]
Well, that's one way to do it. Functions and declarative approaches are more portable across languages in my opinion and good GUI engines should be language neutral. But, I don't want to turn this into a "my GUI framework can beat up yours" battle. There are already topics on that floating around here somewhere. -- Top
There's no such thing as a language neutral GUI engine. The absolute best you can do is serialization to a common file format (HTML, for example) which is displayed by the engine, but you then give up *any* sort of expandability or dynamic functionality not built directly into the engine. When people say "language neutral", they usually really mean "has bindings for the language I prefer", which usually (but not always) is the same as "is written in C"
I disagree.
Oh, so there is a language neutral GUI?
I have not seen an actual case, but feel it is possible.
Oh, so now you agree, and contradict your previous statement. Make up your mind top, either there are or aren't language neutral GUI's.
I don't see a contradiction. And, your tone is unnecessarily combatively.
The possibilities to explore are:
- Is it possible?
- Does it exist?
- Are the concessions to make it neutral worth it?
- If full-neutrality is not possible, then are compromises possible and usable?
Doesn't X-Windows almost do it? Let's explore some possibilities.
First, although I don't like "path-oriented" GUI's, I won't rule them out because I don't want to get into that debate here. Plus, my preferred approach (not described here) can still work using paths. Thus, there is a path to each widget and each attribute. Here are some example API's:
x = getAttrib('formX.textBoxFoo.content'); // get value of text box contents
setAttrib('formX.textBoxFoo.content', 'Hello Neutral World!');
refresh('formX'); // draw in our changes
But most of the GUI setup would be done using XML or some other text protocol. For example, to load a GUI model, we might have something like:
loadGuiXml('root/guiModels/myGui.xml'); // load a file
guiXml('');
Or perhaps
guiXml(filePath, protocol='file'); // same as above
guiXml('http:''''''//www.myGuis.com/blah.xml', protocol='http'); // load from http
Specific attributes could be set this way in addition to the way described above. As far as what the XML protocol might look like, see RemoteGuiProtocols.
I suppose if communication is through XML strings then it is not language-neutral, but bound to XML. But it is meant to be used by multiple languages. Individual languages can perhaps map them to objects and other native language structures. Generally any "language neutral" protocol is probably going to be string-based to some extent, where queries, XML, and so forth are sent via strings. (A database-centric approach can also be devised, but I don't go into that here.) -- top
Tucking layout and config info doesn't make the gui language neutral, someone still has to write the layout program that reads those files... that's us, the programmers, and we use specific languages to do that work.
- I assume we are approaching this from the application developer (domain) perspective, not the system tools perspective. The need for, or possibility of, adaptors for specific languages is acceptable; however, a "string-only" approach should also be available IMO for cases where adoption is not available or not wanted. -- top
I would consider X protocol language neutral. But when you use X from your C or TCL, do you talk to X protocol directly? can you pass C pointer function to X network protocol so that it call you back? No, you can't. You are talking to X through at least Xlib. Using Xlib is no longer language neutral. It's only neutral in the sense that any one could write FFI wrapper over it. But by then they lose all the benefit of their language's semantic (unless their language is already C). X GUI is as language neutral as plain text file is language neutral. It's lowest common denominator of what everyone can do. We almost have language neutral language if all we say is "yeah" and "screaming NOOOOOO". By the way, would you consider being able to talk over network as language neutral? Then Java RMI will be language neutral, because anyone understand RMI protocol could make ruby talk to it (they already have RMI/IIOP though).
The X system is not well-tuned to deal with network latency generally found in HTTP. For example, if you are typing characters into a text box, if every character has to go to the server and back, the user will be understandably annoyed if they have to wait for HTTP to deliver them. Dealing with HTTP requires a higher-level framework where "typical" GUI tasks, such as typing of characters and changing focus, can be handled at the browser level without having to talk to the server for "little things" (unless explicitly asked for). Being HTTP-friendly is a definite requirement for any modern GUI system.
What does "Not well-tuned to deal with network latency" has anything to do with "Being language neutral" here? Performance and concept is different thing. Are you complaining Ruby is not OO because it's slow? Whatta heck.
HTTP is probably not going away anytime soon. Thus, a usable protocol/language should consider it's latency characteristics in its design. Think of HTML forms. It does not have talk to the server to display each character as you type it into a text box, for example. The client-side handles that (by default). X-Windows is not like this; it is more low-level. (It is possible that a GUI setup may opt to manage each character in some circumstances, but it should not be the default behavior.)
In short, X-Windows has latency problems and is too low-level.
Layout and event bindings are the least important part of an GUI. Both of those can be implemented in declarative markup, and thus in a "language-neutral" format. You cannot implement GUI behavior, which is to say the stuff that actually makes it an interface and not a picture, in a language neutral way. If top would like to present a demonstration, I'd be pleased to see it. I won't hold my breath, because the rest of this page shows typical ignorance of the actual implementation of current systems (X-Windows is not a language-neutral GUI engine by any stretch of the imagination....) and an insistence that what he needs to do (simple GUI controls and behavior easily pre-defined by an engine) is all anyone will ever need to do.
First, let's get the "rudeness" stuff out of the way. It was not me who characterized X-Windows. Second, I never proposed only "easy" GUI's. If you have a tough UseCase to present, be my guest. That is the more high-brow way to show how smart you (allegedly) are.
[I presume you won't mind if I delete this page and replace it with pointers to several of the many existing implementations of a layout and event binding language, then? You can move all your ideas to TopsPerfectLayoutMarkup or something.]
{I am not trying to dictate anything here, only encourage discussion and critical thinking.}
As far as behavior, I agree that the entire thing being declarative is not possible. I don't think I ever stated that. If I implied it (where?), it was accidental. The trick is to make the interface between the imperative code and the declarative parts as adaptable as possible to different languages, while keeping expressivity high. The general pattern to events that I observe is something like:
event X(info) {
gav = getGuiAttributeValue(......);
if (gav ...some_condition) {
changeAttributeValue(foo.....)
refreshSomething(....)
}
}
The NounModel should probably be in the GUI engine instead of in the target language. Thus, if one wants to have direct "OOP paths", such as formX.widgetY.attributeZ, then the target language adaptors would have translate between the GUI engine path and the language path.
Now where is that "getGuiAttributeValue" defined in? In C, in Ruby in Lisp? in all of them?
My assumption is that each language would have an adaptor library (unless they use the rawer XML form).
Does the value returned by "getGuiAttributeValue" get cleaned up? By GC, or manually for C/C++?
Isn't that an internal issue within the language? It is not bound to the GUI system. It is merely a local language copy of the attribute from the GUI system.
What's function signature of changeGuiAttributeValue does it require to provide type of the value? (changeGuiAttributeValue("formX.field1", "int", 1)). How will this function be called when the calling language does not support method overloading?
I assumed the GUI system would use strings. Conversion to specific language types would be taken up by the language or language-specific wrappers. It is similar to how databases deal with such issues. If overloading is the way to do it in a specific language, then so be it.
[This, by the way, is how all the existing systems do it. It's sup-optimal because it means it can only be implemented in languages with sufficient runtime introspection that they can do lookups by name. Most current systems also base themselves off the HTML "events as attributes" model, which makes it annoying to bind to an OO framework. Layout languages that don't include event bindings are easier to integrate. Integrating types is much more complicated, because there are very real technical obstacles to passing arbitrary types (especially objects) between languages. There's a number of protocols that address this, however, and some of them are even used in GUI engines.]
How will it notify error, returning error code or throwing exception? Being language neutral is as useful as trying to be Cross platform.
Maybe it can trigger an error event. How do database interfaces do it? Generally it will be something that language adaptor designer will have to deal with. Some languages habit to return codes and others to try-catch blocks.
How do you define the interface which is understood by all language semantic? trying to do that, you end up with very procedural interface. No function callback is possible,
Why are these a problem? Note that OO languages with higher meta abilities may be better able to provide an OO view.
event is done using client keep polling for event and dispatched as necessary.
Why is this so? That seems an implementation issue of the GUI engine, not the language anyhow.
Once someone build a higher level library over it, one will define more semantic to how each object in the system are suppose to interact. It become language independent GUI library. X is still language neutral, but it's UselessTruth IMHO. Yes I would say LanguageNeutralGui is possible, since we have CORBA, SOAP that is language neutral. It's always possible to create a GUI server over that port. But still, it will be as low level as X is.
I suspect X didn't expand partly because of the "HTTP latency" issues. Can you provide some examples of how a CORBA or SOAP GUI interface might look?
Look, my point is that it's how you define "Language Neutral" here. If you define it to be "usable by various language, even through wrapper library" then I have nothing left to argue against. By that definition, WIN32API is language neutral, POSIX is language neutral. Ruby is language neutral (you can write ruby wrapper, right?), everything accessible in binary form is language neutral cause you can write wrapper over it, heck even Machine code is language neutral. But it's as useless as defining that "Everything is something". To be language neutral, it's API and sematic [semantics?] must be usable by all implemented language.
Well, I perfectly agree that "language neutral" is a matter of degree rather than Boolean. The point is to explore those degrees. I am not claiming a final solution here, only kicking around ideas.
[It would be more convincing if you displayed any knowledge of the actual condition of GUI toolkits and the challenges involved in implementing them]
I like to define "Language Neutral GUI" in some way more useful than just to satisfy your desired to prove it so.
"Language neutral GUI engine, of which API differs from language to languages, which different object binding API (because data defined by GUI is just string), Where event handling differs from language to languages (unless one stick to messageloop-dispatch approach)" is possible, but it's useless definition game shit.
Now what makes DB interface different is that it's just the command. it's procedural where it's okay to be procedural. What you do with DB is to just issue the command to insert/update/delete the data from table, when you want and you are done with it. it's sequential separated actions. Now when you talk about GUI, it's parallel interaction, unless you are talking about console GUI. Languages have their own idea of how concurrent activity should work. You set up the interactive GUI view, you may get GUI event at any time, not just when you want to, and you get to display and handle series of various interaction, not just one fix series of SQL command. You may get valid or invalid series of interaction.
Think about it this way, When you are programming SQL you are commanding DB server what to do. When you are programming GUI, you are the one who was commanded to do something. It's always easier to be the one to command than the one that has to carry out the work.
The way I envision it is sort of like CGI: the event runs, changes state (such as GUI model), and then finishes. (However, unlike CGI, it is a messaging system rather than a document/page system). There are no lasting "global" variables and "global" objects, other than the GUI model. (The GUI engine may allow "hidden" variables to act as globals if needed.) Some languages fit that model well, and some don't. But, all languages can be made to fit it to some extent. I suppose some very static languages without any meta features may indeed have to have, or work better with a polling loop. Not the ideal perhaps, but not a show-stopper either. Nothing language-neutral is going be the cat's meow in every language. That is an impossible goal.
And by the way, many things you mention about in wrapper (how to indicate error, how to handle event, the data binding to GUI element) is what i think is needed for something to be call "GUI ENGINE", I want language neutral GUI engine, not Language neutral Dumb white board.
I am not sure what you mean here.
[I'm not the person you're replying too, but certainly to me an "engine" provides driving functionality and power. Markup doesn't provide extensibility or flexibility and, while useful in many cases, is not suitable as a generic GUI toolkit.]
It was related to how you responded to the question about how to handle Event, Error, Semantic with "It's what language-specific adapter writer has to worry." And what's left at your language neutral GUI level is "Post all data as string, Get event by keeping polling, event is just string (no higher level representation)", then it's not GUI engine, It's just X. It's dumb paint screen, it give no concept about data binding, event handling whatsoever. It's language neutral, but it's just language neutral screen server. If you want to advance the technology, think in higher level. 30 years ago one might consider Fortran/C high level language, not anymore so IMHO.
I never suggested app-side polling. I don't see where polling is an issue other than hidden GUI engine implementation details. The language does not have to worry about doing that. But, I still don't understand what your complaint is exactly. What exactly is being "dumb" and what does a smart version of it look like instead? The events are bound to the GUI items, not to the language. When a button is pressed, for example, the Gui eng finds the event program/code/snippet associated with that event and executes it (passing some gui environmental info). Some compromises will probably have to be made in order to make it language neutral, but I see none that are a major hindrance or burden. If you can show a major hindrance, I would be happy to consider it. If you have a better idea of what a lang neut api "should" look like, I would be happy to take a look. Please DontComplainWithoutAlternatives.
Perhaps what you are really suggesting is that the goal is impossible if one wants to use features of their favorite language. That I don't know. It depends on the language. But if that is true, then each language would need it's own GUI engine in order to provide the features and flavor that fit that language. That is not laudable goal if you ask me. There are probably about 50 languages in common use. We would need 50 custom-tuned GUI engines to make all happy, or at least families that tend to fit "kinds" of languages. Still, it makes the idea of language-neutral browsers difficult and is poor reuse. Perhaps some languages cannot handle EventDrivenProgramming driven by external frameworks very well, and they should be dumped into the legacy dump, or at least avoided if performance is an issue.
[Of course it's impossible to be language-neutral and still take advantage of language-specific features. That's why pretty much none of your language-neutral crap, on any topic, makes any sense. There's a reason we have multiple languages, after all. How familiar are you with existing GUI implementations? Do you know the technical obstacles in the way? Do you know how toolkits are implemented? There aren't very many - maybe a half dozen in common use. They all have bindings to multiple languages. We don't "need 50 custom-tuned GUI engines" - we have them.]
I don't see what having multiple languages has to do with GUI limits. I also don't know what you mean by the last part. Are you saying the existing GUI systems are satisfactory? The only technical obstacles are speed and bandwidth (bandwidth being another way to say "speed"). Outside of that, the sky is the limit. See SoftwareGivesUsGodLikePowers. (Well, I suppose that hooking it to existing languages is a constraint.)
"Having multiple languages" has nothing to do with GUI limits, but it has everything to do with being programming language neutral limit. You can have 3D GUI desktop, with Speech recognizing system and fully network transparent. But as long as it is Language neutral, you still have only dumb string puppet GUI, controlling through procedural language and event polling where data has no meaning (everything display just array or 3D point). It's the same problem with Programming language we have now, It's not that our PC is not powerful enough for most type of problem, it's that our programming language is not powerful enough to allow us to think of how to solve the problem clearly.
This sounds like it is turning into a language or paradigm PissingMatch. It may be true that strings and procedural API's are currently the best approaches to provide language-neutrality, but that alone should not stop us from using them. I have not seen enough evidence that they are sufficiently non-expressive to abandon. It may beat the HTML+DOM crap we have now even without being the ideal. In other words, be less crappy.
[At the risk of repeating myself, spending even a few days familiarizing yourself with existing toolkits would be a *really* good idea if you want to have intelligent conversation on this topic. -- ChrisMellon]
{I routinely ignore such insults. I've used lots of GUI systems over the years. It usually turns out to be your lame articulation skills, not my allegedly lacking tech knowledge that is the bottleneck. You just don't want to take the time to explain your complaints properly, believing that insulting my skills is a shortcut. This will probably turn out no different. You've called wolf too many times. Further, you seem to be focusing too much on implementation too early in the game. Let's define what the interface/requirements are, and THEN worry about how to implement it. If we define something that is not implementable, at that point it becomes an issue.}
[There's no insult intended. It helps if everyone involved in a conversation has basic knowledge of the domain involved, including the current state of the art. It allows for common ground in discussion. I'm not sure how my calling you on lacking knowledge of the state of the art is crying wolf, as to my knowledge you've never come back and stated that you actually do have such knowledge. If in fact you do, I'm glad to here it, and I suggest that you frame your ideas in relation and comparison to existing solutions in order to provide a context for comparison.
None of the issues on this page are new, and they all have existing solutions. If you know how people are currently solving these problems, you can provide much better feedback about what you think would be better solutions. If you are intentionally refusing to familiarize yourself with them, which seems to be what you're doing, then I don't see how you expect anyone to take what you have to say seriously. -- ChrisMellon]
The purpose of GUI engine is to provide higher abstraction to using the GUI. GUI engine is not all about GUI-layout, it includes Event-handing, data-binding. While it's true that every programming paradigm's smallest instruction must come down to one procedural command, It is not useful to use the library at that low level. I thought what we are talking hre is about "High-level concept GUI engine" where GUI engine is really an engine that facilitates programming. Or else I think we have no benefit of discussing this topic. Because at the end we have a procedural API which passed all data by string. So, by this definition, we already have language neutral GUI-engine, X, wxWidgets, Tk, WIN32API:GDI, heck most software in the world are then already language neutral, be it X, GCC, OGG encoder, DB, TCL/Tk or Assembly. We don't have to talk about its usefulness to the client language, as long as it can take array of byte and return array of bytes, it's language neutral. So why create atopic about something that's already achieved? Cool invention here, thanks for teaching me that, now clap your hand, you win your definition game here. And we gain nothing for software community. Why don't you create LanguageNeutralSocketLibrary, LanguageNeutralMachineInstruction, LanguageNeutralReportGenerationLibrary.
All of those language neutral library is already there, but IMHO they would be smart enough to not boast their library as so.
- Most are not HTTP-friendly.
Well, for one I don't think that being procedural or string-based necessarily makes them "low level". But arguing over that would probably turn into yet another ParadigmPissingMatch. We've been over similar kinds of issues with SQL and databases. Most of the idioms for CrudScreens can be defined declaratively. This can be leveraged to reduce the amount of imperative processing that has to be dealt with by the app language. The imperative parts are the most difficult to share across languages. We cannot eliminate all possible language-specific issues, but by making as much declarative as possible, we reduce these issues. Good declarative-based systems are not "dumb". I reject your characterization without further evidence. -- top
[The fact that you have to pass SQL to a database instead of being able to create a query programmatically is one of my chief annoyances with existing database APIs. I don't think we've got an optimal solution there.]
- SQL often requires Boolean expressions, and this makes it difficult to fit smoothly into different languages. My contention is that most GUI idioms don't require "expressions", and this is the part we can work on without getting caught up in stuff that does require expressions and complex behaviorial syntax. But even with it's flaws, SQL has been remarkably successful for its purpose. If a GUI standard had similar flaws but the same utility, I'd take it in a heartbeat to what already exists. I'm not endorsing a "string-centric" approach, but if its a decent path to a state better than what exists now, its hard to knock it. -- top
There is some cost in not making the DB tightly-bound to a programming language, but there are also many benefits, such as not having to reinvent the wheel for each language so that vendors can focus on making the best kit. It is better OnceAndOnlyOnce.
[Smalltalk is the only language I can think of off hand that is even slightly widespread, has it's own GUI engine, and isn't capable of using another one. I'm not even sure about the third issue. Java could be another example, depending on how you look at it. Pretty much every other GUI engine can be used from a wide variety of languages. This is due in no small part to the fact that the vast majority of languages can call C library functions, and most GUI engines are either written in or expose a C API.]
But C api's are not latency-friendly over HTTP. Anyhow, it appears that somebody above seems to feel that language-neutrality is not a worthy goal if it hampers using one's favorite language-specific idioms. The thing is, developers often don't make that decision. Many businesses have shown they want LNG's by choosing web-based solutions over fat or proprietary desktop-centric approaches. I have seen it over and over and have converted client-centric tools to web-based solutions due in large part to (perceived) simplicity in deployment. They don't seem to care if development is slow and code messier. A manager is not going to care if you can't use re-entrant virtual closures or whatnot unless it outright stops the project.
Another issue is graphical GUI designers. One should not have to spend much time writing GUI code directly if there are nice tools to do most of it via visual interfaces. I was more productive writing most GUI items with (decent) visual designers than via direct code (such as hand-coded HTML) and many agree. A standardized interface/protocol allows the gui kit builders to focus on the GUI tools (visual and otherwise) rather than time on reinventing such over and over for each different language. The effort can be focused.
This current per-language GUI reinvention for the 30-odd common languages is a massive industry-wide violation of OnceAndOnlyOnce and strangely nobody seems to give a shit. If you demonstrate consolidation is not possible/practical without violating the laws of physics, then maybe it is worth ignoring this ugly mass duplication. Otherwise, stretch your brains, people! -- top
.NET
.NET tries to merge it into a compatible framework that all languages can access. Many agree that there are too many languages. Possibly the old way of linking DLL's together, or using COM is too hard for people. This is why more people are moving to .NET. Although many are still not moving to it. How do you bond scripting languages together with the same compatible sharing system without reinventing .NET? Possibly this is what Microsoft is betting on - the fact that people do choose many different languages, sadly - and not everyone wants to program in C or C++ obviously. Nor does everyone want to program in Java, and only Java. So .NET seems to be fulfilling your request of merging efforts. More serious programmers would consider .NET if it legally worked on Windows, BSD, Linux, and if it wasn't invented by Microsoft. Of course, if .NET was a bit more peppy, it would help too.. I find PAINT.NET extremely slow for all it does, as an example - no matter what benchmarks out there prove that .NET can be fast. In practice, it isn't too peppy for many applications.
.NET fails the "open standard" criteria. MS has a habit of trying to sabotage anything that threatens its desktop monopoly. But if .NET works well, it may spark ideas that can be copied but improved (assuming they are not patented).
What I tentatively envision is a messaging protocol (MP). Let's not get caught up in the language of these messages just yet. That is a later detail. Messages go back and forth between the gui engine (browser) and application. In the past the MPs were designed such that low latency was assumed. But if we want such MPs to work over the likes of HTTP and modems, then we have to do things a bit differently.
For example, take pressing/clicking a menu item or tab to switch screens (change focus). In the earlier MPs, clicking such would often result in a message going back to the app, and then the app would send the "change focus" message back to the gui. This does not work well in a high-latency environment. We don't need a long wait just to browse around to different screens/panels. One approach is to send programming commands in advance to do the focus changing at the browser. However, this carries with it security concerns and requires learning yet another turing-complete language. The second approach is to declaratively specify certain common actions such as focus changes without explicit messages being exchanged upon the event being triggered. Certain such declarative operations need to be identified. (Below under PageAnchor "pre_defined" is a draft list of such items.) Such a declaration may fit the pattern:
widget: Tab7
event: on_click
target_view_panel: myPanel // "main" for top
form: form34
result: give_focus
Keep in mind that this is not meant to replace all programming-bound commands. If we want our app to handle such an event instead of using the pre-defined declarative route, we can. The big difference is this approach requires a back-and-forth message round (latency). It might be set up something like this:
// GUI has been given this declaration:
widget: Tab7
event: on_click
result: send_message_and_wait
// app-side (pseudo-code)
event on_Tab7_click(e) {
....
if (record_count > 200 and my_boss_is_not_drunk_today()) {
giveFocus(view_panel="myPanel", form="form34")
}
}
This does pretty much the same as the first example, but allows complex logic in between and has a latency cost.
-- top
This is start of HTTP related discussion
Many of the existing GUI kits like Tk and X are not HTTP-friendly. A "modern" GUI kit needs to have "latency-assistance" features so that things doable in "declarative mode" or "local mode" are implemented that way. This for both response speed issues and web security issues.
[HTTP is a stateless, transaction based protocol and is inherently poorly suited for the streaming interaction required by a GUI. It's not a failing of existing toolkits. Also, I find your usage of the word "modern" to be suspect, since you are clearly talking about a theoretical concept that suits your needs rather than actual, existing code.]
Streaming? Most GUI activities do not require streaming.
[ALL GUI activities require streaming. Your confusion is natural, though, because you're only familiar with a certain environment and are assuming it's limitations apply in all cases. HTTP is unsuited for streaming, therefore applications which operate over HTTP ensure that all GUI actions occur on the client.]
What is an example of a typical, common GUI action that "requires" streaming?
[Every single user interaction involves a stream of events passing back and forth between the interface hardware, GUI engine and the display manager. Obviously, making every single one of these operations an HTTP request will result in an unusably slow application. This is why it's not done.]
- No. In the vast majority of biz forms I observe, most activity does not require immediate server-side interaction nor complex client-side scripting. Most communication activity only needs to happen when a "submit" or "save" button is pressed. Other things that don't necessarily require immediate server attention, such as changing screen focus when an icon or tab is pressed, are listed below. These can be indicated declaratively. I have studied this issue fairly well.
[See X Windows for an alternative. HTTP/HTML is *not* a RemoteGuiProtocol. It is a local interface to batch processing.]
- HTTP puts constraints on a GUI system.
- Yup, that's what I said.
- Then why did you mention what HTTP/HTML is not?
- I did not write that above. Somebody else did. -- top
As far as "my needs", it is not my needs, but the industry needs. The industry as a whole has decided they want the easy deployment of web-based apps. I agree that certain tasks, such as playing games or editing movies interactively would not be appropriately over HTTP (as it exists now). But we shouldn't dismiss HTTP just because it does not allow every possible need. I am hoping we can identify operations or features which can work over HTTP (latency-bound) and those that can't rather than take an all-or-nothing approach.
[It's nice to finally meet someone that can speak for "the industry". Unless you meant to say "my employer" , or, more likely, "the current buzzword in the IT trade magazines is". A couple years ago the buzzword was "B2B web services" and that didn't exactly dominate the planet. Web applications are very popular for special purposed internal things, the sort of thing you and I get paid to create, but they're hardly the sum of the industry.]
{My observation is that companies are shifting away from fat-client custom apps and moving toward web-based custom apps. If this differs from your observations, then lets just AgreeToDisagree.}
Things that can be done in local declarative mode:
PageAnchor: pre_defined
- Draw screens, or at least "specify" them because "hidden" items may not need to show immediately.
- Navigate between widgets and screens. This includes both user navigation and buttons or events that change focus.
- Rudimentary validation: Validation based on "types" or templates. Personally, I like templates. For example, "999-99-9999" for social-security numbers. "#" is used for general numbers, including those that can have negative signs, and "A" for "token" characters, such as 0-9 and A-Z, and "X" for anything.
- Context-sensitive block-out or hiding - There's often a need to hide or make read-only features that depend on a given selection option. Some kind of set-oriented association mechanism can be used. This requires a lot of attributes to set up declaratively, but is do-able.
Things which usually require client-to-from-server communication:
- Complex validation
- Complex show/hide decisions (beyond what is described above)
One perhaps may claim that these are really "web issues" only, but HTTP is ubiquitous enough now that I don't think a modern GUI can be without it.
[The fact that there is no "modern GUI" over HTTP rather belies this theory of yours. Regardless, you might want to take a look at the XForms standard, which gives everything you seem to desire in a GUI although widespread implementations are probably at least a few years away. This speaks directly to my concerns about your apparent disregard for doing your own homework.
As a final note, this last section really belongs in TopOnWebApplications, or NewWebApplications, or something, because you are *not* talking about GUI engines in general, but specifically about web forms. -- ChrisMellon]
- If HTTP does not matter, then X-Windows already fits the bill more or less. But the industry is moving steadily toward HTTP for good or bad. However, if a good GUI kit exists that works over HTTP, then it could also work client-side. Thus, your dichotomy between HTTP and non-HTTP is premature. You assume an HTTP-friendly standard would not be effective for desktop (fat-client) use also. -- top
Why are you assuming the default is low-latency?
[Where did I do that?]
{I had that impression. If that is not the case, then any proposed standard should be usable over HTTP, since it is quite popular. If a standard ignores or does not work well over HTTP, then it seems logical to ask why. -- top}
As far as XForms, the last time I took a look it was a rather bulky interface and a bit client-centric. -- top
[In what way? It's not any bulkier than XHTML, it's even less client centric because the standard defines a standard way of doing data exchange. In any case I thought you were one of those "damn the performance" kind of guys]
- It is a bulky interface/protocol as far as complexity. I'll try to collect some specifics to post.
There is also XUL and XWT. There is even my pet protocol, SCGUI.
[XUL is already in the list at the top of this page, although I don't think anyone uses it remotely. In fact, I'm only aware of one project that uses it at all, aside from Mozilla. You can add XWT (which I'm extremely unimpressed with) and SCGUI (which I didn't know about) if you want.]
I suggest changing the topic of the page to HttpFriendlyRichClient, since Top seems to focus more on the HTTP/HTML format thing than the GUI engine part. -- AnonymousDonor
Note that I don't care about HTML here. It is HTTP that is the issue, because HTTP is becoming the de-facto message transport standard for good or bad. As far as a topic rename, I guess that depends on how ubiquitous you see HTTP. I won't balk at such a name change. -- top
ProgrammingLanguageNeutralGui name suggests that it's contents should be about how to implements ProgrammingLanguageNeutralGuiEngine. Which is oxymoron by the reason we discussed above (every library accessible through C API is Language Neutral). You seem not to be interested in the feature of GUI engine (Event/Binding). But after the line "This is start of HTTP related discussion", the discussion makes me believe you are concerning about Stateless/Stateful Gui engine. Which is in no way related to LanguageNeutral issue. You can change the topic to ModernGuiFormat if you want; But No, HTTP/Statelessness/XUL has nothing to do with Being LanguageNeutral. Being able to display on Browser is not LanguageNeutral about, that's Cross Platform thing.
Personally, I don't even view HTML as language neutral GUI engine. It's document format, that's all. Every language can produce document of all format, there's no uses to call document language neutral.
I am still not quite sure what you are getting at. How about we study some goals instead of dwell on definitions. These goals may not be reached perfectly, but we can explore ways to get a "good grade" is as many as possible:
- Make it easy to use the GUI engine/protocol with a multitude of different programming languages.
- Usable over HTTP without explicit compile-time bindings, etc.
- ?
HTTP Text Messaging Starting Point
How about we first assume that communication to the GUI Browser will be through HTTP's GET and POST protocol. In other words, text messages (plus a URL). Let's call this the GTPOH - Gui text protocol over HTTP, for now. Now, like CGI, over time wrappers were built over it to make it more palatable. Early adopters will use GTPOH rather directly, perhaps with a sample wrapper in a chosen language(s). Over time, language-specific wrappers may be created that use language-specific features more effectively than the earlier "flat" wrappers.
Thus, we can hopefully get away from language-specific thinking right now and focus on GTPOH and how it builds and manages GUI's. The language-specific thinking just seems to induce HolyWars about paradigms and languages, leaving us stuck in philosophical tar.
-- top
In my opinion ...
The language neutral GUI would allow manipulation of graphics �G� and respond to mouse and keyboard �UI�.
- No disagreement there.
The GUI Engine would handle all aspects of this interface.
- I am not quite sure what this implies. What kinds of things are you trying to avoid?
It would pass information to languages in a non-language specific way (file, memory block, interrupt, 'open api').
- We need to explore that these are. There is no one-size-fits all. Many languages don't have direct HTTP connectability, for example, but that does not prevent an API from hooking into it.
The GUI Engine would also be able to receive data in the same way.
Isn't this what most windows managers do?
All that is needed is to divorce the design, layout and programming of the GUI from the language used to write the non GUI parts of the application.
Take a look at Labview.
- For what purpose? Labview is an application language also.
The GUI IS the Language (almost).
That seems kind of the reverse that is being explored in this topic.
{Please clarify}
Markup Language?
How about we explore a markup language approach. I am not necessarily proposing it, but we may learn something by looking at the strengths and weaknesses.
One issue is event handling. Should the markup code even care what an event is? For example, I am not sure we really need "onClick='function_name'" kinds of things. An event handler can chose to process or ignore what it wants to. In other words, everything the user does is a potential event; but whether something listens to or responds to a given event is another matter. It is like watching parts go by on a factory assembly line where you can chose to grab a given part or ignore it.
However, if we look at the latency issues (and perhaps bandwidth limits) raised by the likes of HTTP, then we may have to pre-label which events are "sent" so that the communications stream is not overwhelmed by every mouse or keyboard movement. And we may need to define common/standard handling rather than make a round-trip to the server each time. Some of this was already addressed above. For example, clicking a button to give focus to (open) another window can be predefined declaratively.
Change handling is another tricky issue with markup languages. How does one insert and delete items after the original was rendered? It can be tricky to address something inside a markup syntax tree. The DOM tree is a flipping mess if you ask me. One approach to handling such is to not allow adding or deleting elements, but instead allow some to be hidden or "silent", and then activate or deactivate them as needed. However, this may impose annoying restrictions.
Further, as described under CoordinateVersusNestedGui, some items seem to work better with coordinate-based GUI's. Ideally, we should have the option of using coordinate or nested layouts for any given window or panel. (These are often called "layout managers" in GUI systems.) Coordinates are possible with markup, but may not be the ideal approach.
Note that unlike HTTP+HTML, I propose divorcing document refreshing from message sending. They should be orthogonal.
-- top
I added TIBCO General Interface to the list. It's an AJAX framework and development environment used for creating web interfaces for applications that expose their functionality via web services or other communication modes based on HTTP and XML.
Recently I've been working on several projects where I found the combination of Hibernate, XFire and TIBCO GI to be an extremely effective way to both rapidly develop applications and provide a ground level for further business logic implementation. Basically, this combo lets me get the CrudScreens out of the way ASAP and concentrate on the difficult stuff. -- IvanStojic
Here's how I might go about it if given funding. First, design a proof-of-concept "GUI browser" that can be defined and controlled largely declaratively. For example, let's assume XML. (I am not a fan of XML, but nobody gets fired for proposing XML [NobodyEverGotFiredForBuyingMicrosoft]). Then make sure it is possible for the browser to send a complete description of a GUI configuration (layout) back to the server or controlling program.
Then devise a way to allow it to send partial configuration info back so that the server or processing program does not get flooded for each little event. First, lets introduce events.
Included would be actions that are easy to define declaratively. For example, a given button can tell a given window to have focus (pop to front). The XML or markup may look something like:
...
// declare button
// bind a "click" event to but1
Note how the event changes an attribute that is already available to windows in general. If a name is already defined, then any new tags with the same name is assumed to be changing its attributes. This keeps things simple. Perhaps there can be an "error if not original" attribute somehow if we really want to prevent such. Example:
The "inform" attribute tells it to let the process/server know that an event happened. However, it does not wait for it. Remember, this focus change is all declarative and the GUI browser takes care of it. If instead we put 'wait="true"', then it would wait for the process/server to respond, perhaps with an hour-glass cursor. (One could call it synched versus asynch communication.) If we wanted to send information about the configuration, then we could do something like this:
This tells it to send a "dump" of all the attributes of "another_window", but not the children (nested widgets). The process/server would simply receive back the XML of the tag with current attributes:
If we had 'children="true"' instead, then it would also send all the containing widget configurations.
In many current systems we have a mix of client-side processing and server side processing. Perhaps we should modify the above tags as follows:
Note the "inform" and "to" attributes now. (I am incrementally adding to these to hopefully keep it clear.) We can notify one or the other or both or none.
The communication with the client and the server is purely via XML (or similar markup language). This protocol would not define language API's. If a language vendor wants to create API's that wrap the XML, that is perfectly fine. However, it is not a requirement.
Here is how the above window focus behavior could be done server side instead. This would be the event definition originally given to the GUI browser:
The server would then receive something like:
Parsing the XML on the server, we know that button "but1" was clicked. Our code may resemble:
function handle_message(xml_obj) {
tag = xml_obj.findByAttribValue("event","widget","but1");
if (tag.found && tag.attrib['action'] == 'click') {
return(''); // request window focus
}
...
}
Another feature would be an optional event sequence counter to make sure nothing gets lost. For example, the server's XML packet for the above event may resemble:
The server may also send a sequence. If sequences get out of whack due to communication problems or other errors, then perhaps the browser can display a warning message with the user option to refresh. The browser-side behavior perhaps could be set via tags that specify one of these behaviors for each destination (client and server):
- Ignore
- Display warning with optional refresh
- Display error message with "quit" or "refresh" options
- Display error and quit (refresh not attempted)
Or, define our own dialog box and actions.
-- top
There used to be DisplayPostscript (in the NextStation) which was a very ProgrammingLanguageNeutralGui. But it wasn't really a remote protocol. Every OS GUI is really a ProgrammingLanguageNeutralGui but these aren't really 'simple' (at least not simple enough to be described by a markup language. Personally I think that a interactive variant of TeX would make a great ProgrammingLanguageNeutralGui (and would make for really simple WYSIWYG).
Amazing. A whole page of this and not one mention of DisplayPostscript. - very recent comment moved to this more appropriate location.
[Does that force people to use the PostScript language though, or send PostScript commands?]
It would make DisplayPostscript the back-end language for display purposes, which would then be viewable by a common set of browsers (and printers).
[Not that this would be terrible, but this would mean it isn't really language neutral since one couldn't use just the native programming language he enjoys. Possibly it is a pipe dream to have a full language neutral GUI - for example, how is Fortran, Forth, or Cobol going to interface into this programming language neutral GUI without sending another language over a pipe? A programming language neutral GUI might end up like SQL where another language is invented and then it becomes a mess in our programs to generate the SQL. But we must KeepAnOpenMind.]
- I dispute that using SQL is a mess. It could be improved somewhat over what it is, but its otherwise successful and I've not seen any significant standardizable alternative approaches.
- I have two questions regarding your competency to make that statement: (a) have you actually read the SQL standard (http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt)? (b) exactly which other options have you analyzed and decided were not standardizable alternative approaches? (i.e. have you even looked, or is that "I've not seen" just a statement founded in ignorance?)
- I thought you were criticizing the SQL string embedding process, not so much SQL language syntax itself. As far as the SQL language, please refer to SqlFlaws.
- Be careful when you say "you". You, it is not the "you" that you think, you! This wiki is written by several people.. not just one person. These comments are coming from different people. In other words not just one person disagrees or agrees. Careful then. That's why some choose to remove signatures, because wiki threads are so confusing and the quotes become mis-attributed.
- I fail to see how lack of signatures is an improvement. If you don't want to use signatures, may I recommend SixThinkingHats to create "local" identifiers to help keep things strait. And "regarding your competency to make that statement" is rather rude. RudenessDoesntWork.
- It is perfectly reasonable to ask you about your competency when you back your statement up with comments like "I've not seen" and "I dispute", but without any logical support. You are, after all, appealing to your competence. I believe it would be extremely rude of you to make such comments without being competent to make them - sort of like someone crashing a wedding when they don't even know who is getting married. It seems, however, you chose distraction tactics over answering the question. Many of the SqlFlaws you waved your hands to gloss over are also flaws in the context of building SQL string commands (e.g. the issue of nesting).
You're correct: fundamentally, it literally and logically impossible to have a truly 'language-neutral' GUI because, no matter what, you (at some point) must serialize a message that determines which pixels ultimately go to the monitor and which inputs the user must provide in return. And that message will, trivially, be in a language, which will thereby no longer be 'language neutral'. The best we can possibly do is create a common back-end language for InteractiveSceneGraphs that is more flexible than HTML and that possesses better optimizations, cache-semantics, and features for the ways we wish to use it (e.g. remote CRUD screens, distributed 3D videogames and remote object control (low latency requirements), distributed tele and videoconferencing, capability security, greater accessibility for non-video interfaces and blind or deaf people, more support for force-feedback inputs and a greater variety of inputs than keyboard and mouse, more flexible client-side 'styling' and transformation of both presentation and interface/input, etc).
ProgrammingLanguageNeutralGui won't happen. It can't happen. Much better would be to go for a powerful open standard for the GUI - perhaps one that uses a more table or data-oriented scenegraph than the current approach (in which scenegraphs are largely tree-based hierarchical). And one could aim to make this scene-graph language, or at least critical portions of it, easy to build and manipulate from a few popular programming languages. But that's as close as one can ever get. And I expect that successive generations of HTML and potentially ObjectBrowsers will move closer and closer to it.
The goal is a continuous goal, not a Boolean one. No standard would make everyone 100% happy, but an imperfect standard can be better than the lack of a standard. The current situation sucks.
{Top, how does XUL differ -- in concept if not implementation -- from your notion of a ProgrammingLanguageNeutralGui?}
So far, its reasonably close, although I've not tested it heavily. However, on the practical side, there is no way in heck that Microsoft is going to support it in their browser, because they see it as a competitor to their browser languages.
{But that, of course, is a political issue rather than a technical one, and few of us here are in a position to directly influence what Microsoft does or doesn't do. Would you say the concept of XUL meets your definition of a ProgrammingLanguageNeutralGui?}
My initial impression from a few years ago was that it relied too much on a scripting language for activities that could be defined declaratively. It also seemed to focus more on web pages than on CRUD idioms. -- top
Huh? Web pages are CRUD screens.. a wiki has a little edit box and page where people create, read, and update content. A web forum also allows people to create, read, update, and delete. Crud can be considered a meaningless BuzzPhrase.
Web standards have not been very effective at creating "heavy-use" CrudScreens in my experience. The available widgets and the interaction between them is either not powerful enough or not reliable enough. I suppose we could create a list of crud-friendly GUI features to avoid miscommunication. Maybe another day. -- top
{Perhaps you should define and implement a PLNG. In the late 80s, I developed one in-house to run on PCs and dumb terminals (via UNIX curses), as part of a suite of tools for developing custom record-keeping and bookkeeping applications (mainly inventory systems, payroll, billing, etc.) Most interfaces could be defined entirely declaratively, with the optional ability to invoke custom C functions in response to certain events or to generate non-standard interfaces. It was quite effective, though outdated by today's standards, and used a compile-time code generator (emitting C code) rather than a run-time interpreted language. A modern equivalent could be useful.}
Definition of PL-Neutral
Give me a continuous and measurable definition for 'programming language neutral', and perhaps I'll agree with the first half. For the latter, I agree: the current situation, which was created by evolutionary forces, could be much better.
SQL and HTML are examples of PLN (programming-language neutral) languages. However, they involve embedding a task-specific language (database and web page specs) in an app language. I would include lang-in-lang as qualifying for PLN. But, I'm not saying L-in-L is the only way to go. RegEx would also be a case of L-in-L.
Which properties make SQL and HTML programming-language neutral? SQL is a language used in programming as much as any other. Is it that they're domain-specific? Or that they aren't TuringComplete? If there was a turing-complete query language, could that be a PLN? Are you saying it's because you build statements of the language from within another? If I put together strings of C-code inside Haskell, would that make C code L-in-L and therefore a PLN? I find your claim here somewhat dubious. Are you just drawing whimsical lines in the sand, or is there a method to your madness?
Let's not turn this into a definition battle. Let's focus on getting something decent for remote GUI's but usable in different app languages 'as much as possible. If we don't achieve GUI neutrality nirvana, let's at least avoid the problems we have now. One step in the right direction is to make as much of the GUI declarative as possible'. In other words, let's isolate what *can* be readily controllable via attributes and very simple commands. Behavior-intensive stuff may be a cross-language problem, but if we can reduce that aspect, then we are closer to the goal. -- top
The idea that 'declarative' is usable in more/different app languages seems to me a highly dubious one.
We'll just have to disagree. In working out how GUI system would work with many different languages, my declarative approaches integrated better in my opinion. I couldn't find a behavior-centric approach that integrated well. If you can find one, please present some examples.
PostScript, SDL, OpenGl, are all supported by a wide variety of platforms and languages, and are behavior-based. Declarative might useful to achieve certain other features (including composition and transformation as per mashups and CSS, and automated optimisation). Declarative is sometimes a bit more secure/confined than app languages, and security is a critical feature for GUI developers accepting remote code; that is, shipping HTML is a better choice than C even if it just came down to security reasons alone. But each of these - composition, transformation, and security - can be achieved in non-declarative approaches. But, relevantly, I have not seen any evidence to believe that declarative is somehow more 'portable'. That seems to be an idea you've latched onto based on some sort of cursory and unscientific analysis you performed years ago.
PostScript is a language more or less isolated by itself. It does not have a lot of interaction, at least not in its regular form. If it has or was used for more interaction between an app and itself, then it would be easier to compare for this situation. It's just, "here's a list of pen movement commands. Perform them and then print a page."
[Actually, PostScript is a powerful, somewhat FORTH-like programming language with strong support for graphics and font manipulation. It has traditionally been used for display and printing purposes, but there's nothing inherent in it that would prevent more general application. I know of at least one case where a general-purpose proof-of-concept was implemented on an HP printer, with the user sending input via the parallel port and receiving output in the form of printed pages.]
But to compare with GUI's, individual components (lines, curves, words, etc.) would be addressed and changed. Addressing and categorizing the "components" would have to be dealt with effectively. In short, it practice it has mostly been only tested as "output only". A pen-up/pen-down language does not natively have addressable components. A noun-centric language would be a better fit than a verb centric for such. Perhaps it can be used that way if certain extra info was added, but that's not where it's been heavily tested.
[Its applicability to interactive GUIs has certainly been tested. See DisplayPostscript.]
How is interactivity dealt with? For example, both of the following draw a rectangle and a circle. At first the rectangle is "under" the circle, but we want to change that on an existing "live" drawing.
// DECLARATIVE PSEUDOCODE
// IMPERATIVE PSEUDOCODE:
pen up
pen to x1=-1 y1=-2
pen down
draw rectangle to x2=1 y2=2
pen up
pen to x=0 y=0
draw circle radius=1.5
In the above declarative, the order drawn defaults to the order listed. Same with the imperative. However, if we want to change the order of the shapes, we change the "z-order", that is the depth level, in the declarative version:
// sent after
This puts the circle "under" the rectangle, which defaults to a z-order of zero. (z-order is the primary sort and definition sequence is the secondary sort if z-order tie.) How to do so on the imperative version is likely messier.
I'm not certain how it is you think changing the z-order of two shapes is particularly relevant to interactivity, but in the procedural approach one would simply associate a z-order translation with the current drawing context procedurally (as a command), which would then affect further drawing commands - something like 'pen to layer
- Remember, we are *changing* an existing drawing. I'm not asking how layering is done on static drawings. I invite you to show your pseudo-code.
-
I suppose I should have made that more explicit. Changing the drawing in this case is the same as changing the variable
and redrawing. If is a global value, this could be manipulated directly. If is a computed variable, then it would either be constant or depend indirectly upon one or more global variables. In general, procedural approaches redraw the entire scene when variables change, though a lot of optimization occurs in determining which areas of a screen don't need to be drawn. In general, variables may also contain more code (i.e. procedures as variables), which allows for some pretty flexible composition.
- I assumed that the procedural language had no "z". The "layering" is determined by the order drawn. It thus does not need a "z", nor layers. If you want something "on top", you simply draw it last (or after what's on the "bottom" of it). If it has layers, then that's a declarative concept, meaning the language is partly declarative, and thus we are comparing lemons to oranges, both citrus. My criteria are generally that if X can be done procedurally, then that's how a "pure" procedural language would do it, and visa versa. In practice most languages/techniques are some hybrid. It's a matter of what they emphasize. Also note that the declarative approach I shown is kind of like OOP without methods. -t
- It isn't unusual for procedural graphics languages to have more than one zbuffer. But you know what they say about assumptions... makes an 'ass' out of 'u' and 'me'. Many languages (including DisplayPostscript and OpenGl) go a bit further than that and allow full 'contexts', where not only does an area get its own z-buffer, it also receives its own brush-type, color, rotation, and translation information, thus allowing for some fairly efficient DeltaIsolation when issuing updates or moving the shapes around. As far as the 'partly declarative', I don't think many people would agree with your use of the language, there, or the implied statement that this is somehow 'more' 'partly declarative' than other procedural languages. Imperative languages have variables. Procedural languages, as sometimes distinguished from Imperative, also have local variables and a call-stack (allowing recursion and such). Z-buffers and contexts fit in quite well as variables. Updating one or more z-buffers followed by a 'blit()' command seems pretty darn procedural to me. It is my impression that you're aiming for a NoTrueScotsman fallacy: "if it works it must be declarative!".
- It's not clear to me which "assumption" you are complaining about.
- You use the word 'assumed' only once in the statement to which I was replying. You'd do well to assume it was that one. (Probably DeleteWhenRead both of these statements.)
- I meant the *example* will assume, not languages that you mentioned.
- How does that make your assumption any better? Is it your intent to assume a crippled *example* procedural language - one that doesn't even reflect the commonly available procedural techniques - then compare that to your declarative approach?
- I dispute them being procedural.
- Indeed you do. I note your HumptyDumpty definition of declarative that you invented on the spot and wrote into your 'book' just so you could raise aforementioned dispute. I don't believe your dispute has any merit.
- It was not a definition. See below.
- I agreed that some of the mentioned languages may have declarative features.
- That's funny. I don't remember proposing that the mentioned features have any remarkably declarative features, so how could you 'agree' to it? Are you agreeing with yourself? What I said is the opposite: I suspect that most people would reject your claim about a system being 'declarative' merely by virtue of it having multiple z-buffers.
- If there is a layer or a context and it is "addressable" and has attributes that can be changed, then in my book it is "declarative".
- I don't have a copy of your book - and don't want one. Other than you, I've never heard anyone call 'addressable' components 'declarative'. Pushing contexts around like pieces of paper and playing with z-buffers like cellophane sheets would be considered OOP if it was done by commands to the objects and they had to move/draw themselves, but manipulating them in a context with sequential commands in response to global and computed variables is classic procedural.
- However, I will agree that the distinction can be blurry and that hard boundaries are either hard to find, or have too many exceptions. But we often have to create fuzzy abstractions in order to communicate. If one can change "attributes" of "things", then generally it is declarative, or at least "declarative-oriented". I vaguely remember a topic that debated the diff between "declarative" and "imperative". Maybe if we find it we can prevent a duplicate LaynesLaw battle. ;-)
- Why attempt to overload the already overburdened 'declarative'? Why do you insist on communicating with others using definitions that exist only "in TopMind's book"? Why not use the "fuzzy abstractions" that already exist for the concepts you're discussing?
- Sigh. Perhaps you should come up with a features list. Focus on language-features that are measurable objectively if your disgust for formality keeps you from making them boolean-qualified. Order the list of features by what TopMind's book says is the order of relevance for ProgrammingLanguageNeutralGui. Call that something other than "declarative" - actually, try to avoid using any words already usurped by the technical jargon - and we can avoid a LaynesLaw battle. (page anchor: a more productive path)
- It's not "usurping". It is not defined clearly enough as is and I don't think it is possible to define it clearly enough because each language can invent its own little world with new rules. DataAndCodeAreTheSameThing. It's fairly easy to project one as the other. For example, adding accessors like set/get can turn a declarative interface into an imperative one, at least in name.
- Is it your goal to take a word you believe is not defined clearly enough and toss an entirely new interpretation into the mix and thus confuse things even further?
- What exactly makes it "new"?
- The fact that you can't point to anyplace but TopMind's "book" that has a definition of 'declarative' that would put "addressable and has attributes that can be changed" into the declarative category. Or am I mistaken? Can you find me a "not new" definition of declarative that supports your claim?
- Where is this official definition that lacks any room for subjective interpretation? Your response assumes one exists. Otherwise, DontComplainWithoutAlternatives just so that you can argue about arguing. And please, none of that "intent" crap of yours.
- Huh? I do not assume an 'official definition' of declarative exists. What I said is that, of all the programming definitions of 'declarative' out there - except the one you made up - I know of none of them that put "addressable and has attributes that can be changed" into the declarative category. Can you point to one that clearly gives you that much room for "subjective interpretation"? Actually, and more relevantly, can you honestly say you're using any established definition of 'declarative'? I think not. Cut it out with this HumptyDumpty crap of yours.
- Re: "I know of none of them that put...". That is because such is a *specific* manifestation of declarative. Pure functional programming, for example, is often described as "declarative". However, the def itself does not explicitly list functional.
- Then find me the definition for which this is a *specific* manifestation. Sigh. Whatever. It seems you reaaaaally want a LaynesLaw battle, because you're still fighting to use words in ways I'm not willing to read them. It doesn't even matter whether one of us is 'right'. And it could all be miscommunication (I really don't see how your 'pure' approach of drawing to one z-buffer then issuing a "showpage" is somehow 'less' declarative than drawing on many z-buffers then issuing a "showpage" that collapses them one atop the other, but perhaps you're imagining something else). Please consider (page anchor: a more productive path).
- I'm not sure what you mean here. The imperative version I used had no explicit level buffering. The order drawn determined what is "on top" of each other, similar to a physical drawing/painting where one has to put bottom layers on first (barring some nasty scrubbing or erasing tool).
- So? And? You already have 'screen' buffering, which by any measure is simply a single z-buffer. It seems like your logic is: "okay, if we instead have a stack of z-buffers that we procedurally manipulate and another 'pen' variable indicating to which one we're drawing, definition and logic magic happens here, and because of this the relevant aspect of the language is declarative not procedural anymore". Now it's time to point me to the definition and expose the logic that makes this magic happen. URI. Book title and Page number. It should be easy, at least if you were being honest when you said this "is a *specific* manifestation of declarative." My guess is: you were lying through your teeth. But I'm willing to be proven wrong.
- The existing definitions are subject to interpretation. I cannot provide any objective Boolean-answer test because none exist. That's just the nature of the beast. We cannot pretend like clinical precision exists when it doesn't. You are displaying artificial anal-ness.
- Which existing, established definition is subject to this particular interpretation? Nevermind. You have now confirmed that you were, in fact, lying through your teeth and now you're HandWaving to cover it up.
- They ALL are subject to interpretation (of some kind). I challenge you to find one that is not. And if you do, please move it to DeclarativeDefinition or the like. Further, you haven't shown that the "noun with attribute" model has obvious imperative features. You only have to find one to attach some doubt to my determination.
- I don't care about subject to interpretation "of some kind". It isn't even relevant if they are, because being subject to interpretation of some kind does not imply being subject to interpretation of a particular kind. Find me an established definition subject to the particular interpretation to which you're subjecting it. Your HumptyDumpty games with language and logic are unacceptable. And if you want a similar example: "Pen up". Noun, modified attribute, directly from your 'pure' imperative example. "Pen to buffer 3" "swapBuffer 3 4", etc.
- Exactly! One can *interpret* nouns as verbs and vise versa as described in DataAndCodeAreTheSameThing. EverythingIsRelative. It's all "in the head". I'm just the messenger. If that bothers you, I'm fricken sorry, dude.
- When you're done dancing around like a punch-drunk fool who scored a touch-down victory in the wrong end-zone and hasn't realized it yet, feel free to point me to an established definition of 'declarative' that is subject to the interpretation that "nouns and verbs make it declarative". And, perhaps, tell me which point you think you won.
- I have not found any definition that is objective enough to perform Vulcan-passable logic on. Now if your argument is that "one cannot talk about country music until they first objectively define country music", then please say so. Your position is wishy-washy. Take the common "what versus how" definition. That can be bent any which way. There is no objective and consensusly accepted algorithm that can take a lang def and spit out an either/or answer.
- My argument is more similar to: "You haven't convinced me this Pop music is actually Country music simply, and your declarations that it's true in your book, your pointing out that the two musics probably blend somewhere, and so on seem like sophistry and HandWaving to me." Even if I agree there are no hard lines between Pop and Country, or between White and Yellow, or between two seasons, and so on, I consider it your fallacy every time you say that the two can't be distinguished. Declarative and Procedural actually have a stronger distinction than Country vs. Pop: what vs. how can be layered, but cannot be blended.
- Discussion being moved to DeclarativeImperativeDefinitionDiscussion.
- And I'll believe it's "easy to project" from one thing to another when you can give me 100% free (in space and time and programming effort) views and indexes and queries in an RDBMS. At the moment, my belief is that translation and projection are pretty damn substantial tasks. Ignoring their relevance seems to me like eating some topsoil and spinach seeds then declaring you've had your vegetables.
- This topic is not about RDBMS.
- True, but I'm quite excused from going a little off topic after you started rambling about how "DataAndCodeAreTheSameThing" and how it excuses your abuse of language. The above is in response to your claim about how "it's fairly easy to preject (sic) one as the other". It is not easy to project. The idea that views are insignificant is not one with any merit. If the idea that views are insignificant, cheap, automatic, etc. did have merit, then views in RDBMSs, transformations, translations, and related computations would be insignficant, cheap, automatic, etc. They aren't. Reductio ad absurdium. Q.E.D.
- If I said something pivotal objectively wrong, then you are welcome to prove it using semi-formal logic.
- If I said: "Pigs fly", could you disprove it using logic? You're free to try; maybe I'll learn something. All I know how to do is point out fallacies and approaches to thinking that are well proven to lead people to bad conclusions. For example, your most recent statement was a suggestion that I should bear the burden to disprove your claims, which is ShiftingTheBurdenOfProof. As another example, I recently pointed out your StrawMan attacks in FileTreeMeetsRelational. A logical person would understand these to be errors; you, however, think of 'straw-man attacks' as 'points successfully defended' (ignoring that it wasn't a relevant point), and you've already expressed your opinion in ShiftingTheBurdenOfProof. I can't convince an irrational person of anything. You'll go on believing what you wish, truth, logic, established language, etc. be damned.
- Please don't spill over spats across topics if not necessary.
- Please stop making it necessary.
- It's not necessary.
- And pigs fly.
It is clear your understanding is heavily influenced by the DocumentObjectModel. I won't knock DOM - it and related models such as SceneGraph are among my own favorites for reasons related to delta isolation and style-transformation (not portability). But I think you need to work with a few other models before you can start arguing which ends up 'messier' in final implementation, especially when the implementation you're talking about is usability across languages.
I am trying to illustrate points, not simply claim I am smarter than X.
I appreciate the effort, but when it comes to illustrating that 'declarative' is more usable/friendly across application languages, the topic of manipulating z-ordering of a couple drawn shapes seems to be unrelated. I think I'd appreciate your efforts more if you were aiming to illustrate clearly relevant points.
Use in Native Language?
When people ask that they can use the GUI standard in their "native app language", how much integration is needed? Suppose the standard was some kind of markup language. If you didn't want to use the markup language directly, wrappers could be created for the native app language. Whether these wrappers could take advantage of all your favorite native language features is hard to say though. I expect some kind of compromise would have to be made. It's hard to be a generic standard and fit the style of multiple particular app languages at the same time. That's the usual case with standards. But I feel it would be worth it. (I know, some of you said you don't care what I feel. You don't have to repeat it, I already know you love my guts.) -- top
While Top is focused on Declarative PLNGs, I think we could do a very good and flexible job by pushing for more powerful and secure support for distribution of mobile code (e.g. ObjectCapabilityModel security), and direct access to OpenGl viewports (+sound ports) as output and a collection of abstract input devices that may be subscribed. This can be supported by a framework that can be ported to different languages.
The ability to distribute code to both sides of the link would do a great deal to allow optimizations wrgt. network chatter. Support for powerful security and additional protections for the machine (no consuming all resources), the application (no deadlock), and one's privacy (i.e. a page mashup shouldn't mix up which details go to which server), however, are necessary before people will feel particularly comfortable with offering sufficient power to the distributed code. EeLanguage is powerful enough on the security end, though we'd also benefit from a language with greater support for optimizations and automatic distribution.
There are plenty of challenges where a more declarative language still helps a lot: support for accessibility by the blind and/or deaf, intelligent integration of mashups, support for some equivalent of CascadingStyleSheets to allow changes in presentation or to make 'mashups' consistent, intelligent mapping of input devices based on current focus of user, ZoomableUserInterface, etc. I'd consider it a GoodThing to tackle these problems, and solve them well, and perhaps a declarative solution at some stage in the processing would help us there.
However, even if higher-level declarative concepts form the lowest 'layer' for the viewport and InteractiveSceneGraph, I don't think we'll ever escape the need for effective distribution of secure, optimizable mobile code in a GeneralPurposeProgrammingLanguage.
I agree that some kind of "local scripting" or behavior plug-ins will be a popular option, but most of the common "behaviors" can still be defined/applied declaratively. This also makes it easier to not hard-wire the spec to a particular programming language. And, what you describe is fairly close to Java's GUI approach, with it' sandbox model and all.
A few behaviors can be declaratively defined. We can try to make those the common behaviors, I agree. But I'm not convinced that it is worthwhile to do so, nor am I convinced that it "makes it easier to not hard-wire the spec to a particular programming language". I think your approach of aiming for 'declarative' is an utter waste of effort when one will later be hacking in a scripting system around it that will be the "popular option" anyway. One would be much better off with a coherent "particular programming language" that just happens to have some high-level commands (or even just access to a standard browser-provided object or API) that allows many common "behaviors" to be expressed as one-liners.
- Your viewpoint is noted. Some organizations, especially those interested in higher security, may only want to use the declarative abilities of the GUI standard, doing more of the processing on the server, and living with slightly longer lag-times because of it.
- Security is a concern, which is why it was mentioned in the first paragraph, and the second, and mentioned EeLanguage. However, I do not believe "declarative abilities of the GUI standard" offers greater security than you can obtain with ObjectCapabilityModel, and what measure of security it achieves is gained by sacrifice of flexibility and performance - unnecessary sacrifices upon the altar of "I really can't be bothered to search the wide space of design permutations for something that avoids these sacrifices and still offers security". Organizations interested in higher security would rather obtain it without giving up on flexibility and with minimal loss to performance, and certainly don't have their hearts set on limiting themselves to declarative GUI behaviors.
- ObjectCapabilityModel has not been field-tested enough for my tastes.
-
Lol. I suspect, based purely on my belief that you're a stubborn old coot, would be that you don't think it will be 'field-tested enough' until hearing about object capability model through layman outlets (i.e. well after intelligent technical experts believe it has been field-tested enough). Hearing about it through layman channels may happen within the next few years, as the next generation of JavaScript and DOM is based on capabilities in order to better support secure page mashups. ObjectCapabilityModel overcomes the privacy issues that are protected today by JavaScript's current, and rather severe, limitation of only sending AJAX messages to the originating server. The preliminary work in this vein is called 'caja' and was performed by Google. Caja enjoys usage today protecting the users of Yahoo! Application Platform. Anyhow, reflecting your original statement: basing security on some misguided belief that declarative is inherently more secure has 'repeatedly been proven false infield-tests (SqlInjection and the aforementioned privacy issues for mashups, just to name two examples) - which is far too often for my tastes.
- This not the place to (re) evangelize OCM.
- Sure it is. It relates to the goal of flexibly supporting GUI stuff in a portable way that is "reasonably latency-friendly, such as not requiring each key-stroke to travel both ways before a character appears, as found on HTML forms".
- And I do not wish to tie a GUI system to specific paradigms and syntaxes. Otherwise, one's goal is no longer a ProgrammingLanguageNeutralGui, and thus is another topic.
- We've already discussed at length your failure to provide any reasonable definition of "programming language neutral". If by "programming language neutral" you mean "portable to a wide variety of different languages and platforms", then discussing the possibility of using a common language tied to specific paradigms and syntaxes is perfectly on-topic so long as portability is covered. If by "programming language neutral" you mean "declarative", despite the tenuous-at-best association between portability and declarative nature, then perhaps your goal is 'DeclarativeGui' and thus is another topic.
- Like I said, it's a 'matter of degree; something most formal definitions don't tackle well. (See DefinitionOfLife for an example of a def of a common concept with a similar problem.) The general descriptive metric is that one can rely less on their app language to do or handle "typical and common" GUI stuff. And, without resembling an app language itself.
- You said it was a 'matter of degree' in your typical EverythingIsRelative manner, but you still failed to provide a reasonable definition when called upon it (asked for a 'continuous' definition to describe that 'matter of degree') at the topic area titled "Definition of PL-Neutral". Your most recent 'descriptive metric' tosses aside concerns for portability in favor of: if it has some high-level primitives for common display operations, it's closer to neutral. Does 'PL-Neutral' more or less mean 'high level' to you, now?
- Portability? Please clarify.
- Your earlier words were: Language neutral - Easy to port API's and/or use markup with many different languages. Problem for you is that declarative (by the commonly accepted definitions) fails here.
- As far as a general definition of "declarative", I did not invent the term. If this discussion depends on a clear definition of "declarative" to continue, then let's work on that first at DefinitionOfDeclarative. Related: DeclarativeGui. -t
- You did not invent the term, but you certainly set out to re-invent it. But the definition of "declarative" was not at issue in this discussion. The definition of "PL-Neutral" is. The only reason "declarative" gets involved is that you're pushing an agenda. It looked to me like you were attempting (illogically) to assert that "declarative" implies "Easy to port API's and/or use markup with many different languages". Hah! You try it. You finish implementing TopsQueryLanguage yet? You even started on an API?
- Let's try this: do or handle as much typical and common GUI idioms and patterns as possible without being (or needing to be) TuringComplete. -t
- I suspect by "not TuringComplete" you really mean "provides a guarantee of termination" (which it isn't implied by merely being 'not TuringComplete'). And a guarantee of termination IS a nice guarantee to have for many purposes. So is totality (= terminates PLUS freedom from error). So is determinism (= result same for every run). Hmmm... are there any other guarantees we might like? security, perhaps? It might be a bit difficult to properly port an insecure PL-Neutral GUI to a secure language, after all. Perhaps what you're aiming for, fundamentally, is PrincipleOfLeastPower?
- Yes, I generally agree with PrincipleOfLeastPower for this because I believe most want a better standard GUI system, not a new programming language, and not a weird academic experiment, but with the caveat that it also be comparatively easy to integrate with app languages. -t
- Sorry, I don't follow. In fact, I suspect that achieving PrincipleOfLeastPower pretty much implies a 'weird academic experiment' relative to what is available today.
Anyhow, I was not suggesting a "local scripting" system. I don't think it a totally bad thing, but it was not what I was describing above.
I suggested mobile code + direct access to viewport (and other ioport) resources, and possibly allowing a declarative solution at a stage in the processing (e.g. that might be compiled down into the viewport code). There are more than a few differences, wrgt security and automated optimizations and especially interactivity with external systems, between embedding scripts in a declarative InteractiveSceneGraph that will be called based on user behavior vs. putting arbitrary complex service objects near a viewport that can BOTH react to user-behavior (and update external systems appropriately) AND receive messages from the outside (and update the viewport accordingly). You've been proposing a "static" model for documents. I want a "live, dynamic" model for data-fusion documents + games + video-conferencing + command-and-control and so on.
And, yes, Java 'applets' and their sandbox have many superficial similarities. However, we could still do much better; there are many 'API' choices to make for how such 'java objects' interact with the browser and with one another. Support for navigation, composition, zooming, level of detail, user-focus, etc. must be built into the API for both the ObjectBrowser and the objects... features related to the sort of composition and mashups and navigation we wish to perform. Java objects and applets lack the sort of uniform or global address space necessary for composition, browsing of remote systems, etc. Mobility for java objects in applets is also limited. There is some little ability to download new code based on current interactions (well, I'm sure you can do it, but it is painful, whereas it should be easy - even implicit and automatic... as easy as referencing or creating an object), and there is even less ability to go the other direction and inject servelets back into the servers in order to optimize one's communication with them. Support for bidirectional mobility would allow display configurations to automatically optimize interactions with servers, performing mashups and data-fusion and navigation between them.
See also: RemoteGuiProtocols, EventDrivenProgramming, NonOopGuiMethodologies, GuiMachineLanguage, GuiMarkupProposal