关于基于DHTML的RichClient的一些想法

1. 采用声明式编程，例如在然后将id和对应的JS对象绑定起来，这个span就成为界面组件的占位符
2. 建立 JSON - XML - Java的映射渠道，以XML为中心，所有的XML可以marshal成为json，从而可以在js中轻松处理，而无须DOM进行访问。在服务器端，则基 于Jaxb2。支持在浏览器端使用js处理复杂数据结构，例如CubeView/CellCell这样的复杂结构。
3. 基于json-rpc的机制，让js可以轻松的调用java的代码，并且可以交换复杂的XML数据（在客户端直接通过js访问，在Java端直接通过jaxb2访问），初期甚至可以让组件的render方法都使用java来实现。充分利用服务器端的开发环境。
4. 服务器不维持状态，但可以cache数据。状态维持在浏览器上进行。比如说CubeView，可以保存在浏览器上，在进行请求时，可以仅传递 对象的ID，在服务器上将在cache中进行查找，如果不能找到，服务器可以产生一个异常，客户端在检测到对应ID的Cache不存在的情况下，把这个 ID的对象存储到服务器的Cache中，然后再次重复请求。通过这种方式，可以在服务器不维持状态的情况下，同是尽可能的减少数据的传输量。这些数据被称 为UniqueIndexedData。
5. 部属方式上，初期可以绑定Firefox进行产品的发布，在后续的时候，再进行IE的支持。在图形的处理能力上，可以通过applet的方式 来进行本地的render处理。如果在服务器声称chart然后传递到浏览器上，可能会比较复杂，但可以作为一种实现的手段进行保留。
6. 关键点在于以数据为中心，数据结构一定要设计清晰，易于处理。UI组件保持较大的可变、可替换性，可以根据需要进行开发，或者切换到新的开发环境上去。
   

LLVM

VM的概念越来越成为潮流了，一个称之为 LLVM 的VM带来了一种新的概念。http://llvm.cs.uiuc.edu/

在 JVM 或者 .NET 的世界中，VM其实是一个面向对象的强类型的虚拟机，而不是一个面向内存的虚拟机，这样的虚拟机与CPU的级别还相差较大。而传统的CPU还是典型的冯- 诺伊曼体系结构的计算环境，在这样的环境中，最为典型的还是寄存器-内存的基本模型。没有对象的概念，只有内存。

LLVM 作为一个虚拟的冯-诺伊曼机，其距离显然相对于 JVM 或者 .NET 来说，要更直接得多。 所以，JVM 如果再基于 LLVM 之上，未尝不是一种很好地实现方式。与JIT相关的部分将更多的在LLVM上完成，让JVM更多的定位在一个对象化的JVM之上。

而且基于 LLVM，可以更加简化的讲各种其他的语言翻译成机器语言，例如 Haskell这样的语言，如果翻译成为LLVM的话，那么，就可以充分的利用 LLVM 的JIT技术，从而获得高效的执行。

从这个角度上来看，抽象本身就是一种很好的代码服用，通过对现有的复杂世界进行抽象，从而定义一个抽象层（在这里时VM），把各种复杂的细节进行屏蔽。再在这个抽象层上进行更高层次的思考、开发。这个远比单纯的对象抽象带来的复用带来更高的价值。

Smalltalk Blue Book

http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_imp_toc.html

经典的资料啊。

Simple XUL Designer

在一个基于XUL/XHTML/SVG的UI环境中，我想可以设计这样的一个Designer，来提供可视化的设计能力，提高UI的开发效率。

1. XML Source Editor 提供基于source的编辑，可以提供基于XML Schema的code complete、verify、tips等功能。同时，在source编辑时，可以加亮UI部分，或者显示当前部分的DOM Path。
   
2. Visual Editor提供对UI的可视化编辑。可以提供inline的编辑功能、基于popup菜单的编辑功能、customizer的编辑功能、properties editor的编辑功能。在这里，inline的编辑功能可能相对最为复杂。
3. 双向结合XML Source Editor/Visual Editor。在source中进行的改动可以同步到UI中，而在UI中进行选择，可以自动同步到XML中。
   

同时，对于脚本支持，也可以提供现代的编辑技术，主要是code complete方面的支持，将可以大大的提高开发效率。

在对脚本语言的支持上，我觉得也不一定只偏重于javascript，我觉得对java进行支持也是一个很好的选择。java本身可以是安全的砂箱模型， 而且提供了开发时的强类型特性可以提高开发的效率。一个好的IDE可以自动地将DOM中的对象映射成为Java中的强类型对象。

在一个好的基于XUL的开发平台中以及支持的开发工具支持之下，将可以有效地提高UI的开发效率和维护能力。通过提供一些基于领域的XML UI，可以极大地简化UI的开发工作。

比如说，Graphic Editor Framework如果在新的模式下，可以会有新的思路，因为XML提供了很好的一个中介层次，非常适合于进行UI的表示。软件开发人员可以根据需要开发适合的中间语言来表示UI模型，并带来更大的可维护性。

从这个角度上来看，是非常有必要在Java中引入XUL支持的。

开放框架:提供好的调试能力

在软件开发中，调试是一个很重要的手段，如果一个操作系统、开发语言、开发框架、开发工具不能提供良好的调试手段，会严重的导致这个系统的可用性。

以WEB开发为例，FireFox就提供了两个很好的调试工具：
1、DOM inspector
2、JavaScript Debugger

如果进行UI的开发，DOM inspector确实提供了一个很好的帮助，但是如果能够提供一个Visual Editor则可能会提供更大的帮助。

从Firefox的Dom Inspector来展开，我觉得在UI方面，基于XML的用户界面应该是很有前途的，这是一些想法：
1、XHTML 毫无疑问是WEB UI的重要基础
2、XUL 提供丰富的Rich Client的UI支持
3、SVG 提供矢量图型的支持
4、MathML 提供数学领域的支持
5、 根据领域的需要开发新的UI，遵照DOM模型。

从开发的角度上来说：
1、UI Render 负责进行显示的处理。在一个统一的模型下结合上述的UI功能。
2、Visual Editor 提供一个统一的设计框架，各个子UI可以在此基础上进行开发。
3、 DOM Inspector
4、 Script Control, More Control Language Support.

Harmony Project

Apache计划新开设一个harmony项目，提供一个Opensource的J2SE实现，这个计划还在草案之中，maillist就已经热闹非凡了。

我提出的使用Java来实现JVM可能是到目前为止最为热闹的一个论题，支持和反对者都非常的多，反对者很多的是认为不可能，而支持者则认为能够最大化提升JVM的可维护性和可扩展性，可能更为加速的发展JVM。

JSR 273: Design-Time API for JavaBeans

JCreator Design Time API --　DesignInfo
JavaBeans -- BeanInfo
JMX -- MBeanInfo

Beehive Controls

架构师与程序员之间的区别

在JavaWorld的一篇文章中，作者谈到了架构师与开发者之间的区别，并指出大多数人似乎并不了解这种区别。

作者指出，从大多数招聘广告上，我们很难看出"高级开发者"与"架构师"究竟有什么区别：两种职位要求的技能几乎相同，似乎只有经验深浅的区别。然 而作者认为，这两种角色有一个根本性的区别：高级开发者的职责是"在给定的环境下解决问题"，而架构师的职责是"创造能够解决问题的环境"。