Subverting the JCP - Why?

Just read this post by Java lead Mark Reinhold in which he says that

It's therefore time to define a simple process for collecting, sorting,
reviewing, and prioritizing proposals and plans for new features, for
JDK 8 and for later releases.

Some essential requirements (not in priority order):

- As lightweight as possible.

- Simple mechanics.

- Version-controlled, so that changes can be tracked.

- Open to all committers, with transparent decision-making.

- The basic format should not be too different from (a simplified
form of) the old Sun "one-pager" template [1], with which many
are already familiar.

- An approved proposal should be able to serve as the authoritative
source of the summary and reference information needed for related
documents such as the release feature list [2] and the Platform
Umbrella JSR specification [3].

[emphasis mine]

A big problem I've seen with the JCP is this desire to use it as a rubber-stamp for JavaSE rather than, as most other JSRs including the JEE ones are, an actual debate on what needs to be done. I agree with soliciting feedback from a wide community and making that open (I'd argue that the JCP should be open ala OASIS) but I really don't get why we need a proposal mechanism outside of the JCP to manage this unless the ambition is to purely manage it from an Oracle/OpenJDK perspective rather than as an actual part of the Java Community Process. The proposed approach smacks of the pre-JCP days where Sun solicited feedback and controlled the process and which the JCP was set up to change.

I'm depressed, I'd like to see the JCP successful and the voices listened to not a new process created outside of a standards group and controlled by the leader of the JSR who will then present it to the JSR team as a fait accompli which is exactly what led to the debacle with JAX-WS and the problems that it delivered.

Announcing the HTML5 dynamic layout manager

One of the challenges I've found with the latest HTML 5 frameworks is that they require a significant amount of hand-coding and when looking at things like proportional layouts it can get pretty tricky if you need to do complex layouts. Now things like Buttons and the like are of course there and all the basic primitives but what I'm really after is something where I can do some complex layouts and set stuff like the piece of the page with initial focus.

From a mashup perspective I want to be able to nest these layouts so I can create pages out of various sub-fragments and enable people to quickly create "trees" of independently created layouts, ideally enabling all of this to be done using a visual building tool.

So I looked around and I'd now like to announce 5Form, probably the most powerful layout manager available today and one designed for the mashup challenges and complex interfaces that the web requires. Proportional layouts, inter-widget layout dependencies, dynamic resizing and more are all automatically handled by this new powerful layout manager

NAME

5Form - The HTML5 dynamic layout manager

5Form is a dynamic HTML5 container with no input semantics of its own.
Constraints are placed on children of the 5Form to define attachments
for each of the child's four sides. These attachments can be to the
5Form, to another child widget or gadget, to a relative position within
the 5Form, or to the initial position of the child. The attachments
determine the layout behavior of the 5Form when resizing occurs.

The default value for 5NinitialFocus
is the value of 5NdefaultButton.

Following are some important considerations in using a 5Form:

• Every child must have an attachment on either the left or the
  right. If initialization or 5SetValues leaves a
  widget without such an attachment, the result depends upon the value
  of 5NrubberPositioning.
  

  If 5NrubberPositioning is
  False, the child is given an 5NleftAttachment of
  5ATTACH_FORM and an 5NleftOffset equal to its current
  x value.
  

  If 5NrubberPositioning is
  True, the child is given an 5NleftAttachment of
  5ATTACH_POSITION and an 5NleftPosition proportional to
  the current x value divided by the width of the 5Form.
  

  In either case, if the child has not been previously given an
  x value, its x value is taken to be 0, which places
  the child at the left side of the 5Form.
  

• If you want to create a child without any attachments, and then
  later (e.g., after creating and managing it, but before realizing it)
  give it a right attachment via XtSetValues, you must
  set its 5NleftAttachment to
  5ATTACH_NONE at the same time.
  
• The 5Nresizable
  resource controls only whether a geometry request by the child will be
  granted. It has no effect on whether the child's size can be changed
  because of changes in geometry of the 5Form or of other children.
  
• Every child has a preferred width, based on geometry requests
  it makes (whether they are granted or not).
  
• If a child has attachments on both the left and the right
  sides, its size is completely controlled by the 5Form. It can be
  shrunk below its preferred width or enlarged above it, if necessary,
  due to other constraints. In addition, the child's geometry requests
  to change its own width may be refused.
  
• If a child has attachments on only its left or right side, it
  will always be at its preferred width (if resizable, otherwise at is
  current width). This may cause it to be clipped by the 5Form or by
  other children.
  
• If a child's left (or right) attachment is set to
  5ATTACH_SELF, its corresponding left (or right)
  offset is forced to 0. The attachment is then changed to
  5ATTACH_POSITION, with a position that corresponds
  to x value of the child's left (or right) edge. To fix the
  position of a side at a specific x value use
  5ATTACH_FORM or
  5ATTACH_OPPOSITE_FORM with the x value as
  the left (or right) offset.
  
• Unmapping a child has no effect on the 5Form except that the
  child is not mapped.
  
  
• Unmanaging a child unmaps it. If no other child is attached to
  it, or if all children attached to it and all children recursively
  attached to them are also all unmanaged, all of those children are
  treated as if they did not exist in determining the size of the 5Form.
  
• When using XtSetValues to change the
  5Nx resource of a
  child, you must simultaneously set its left attachment to either
  5ATTACH_SELF or 5ATTACH_NONE.
  Otherwise, the request is not granted. If 5Nresizable is False, the request
  is granted only if the child's size can remain the same.
  
• A left (or right) attachment of
  5ATTACH_WIDGET, where 5NleftWidget (or 5NrightWidget) is NULL, acts like
  an attachment of 5ATTACH_FORM.
  
• If an attachment is made to a widget that is not a child of the
  Form, but an ancestor of the widget is a child of the 5Form, the
  attachment is made to the ancestor.
  

All these considerations are true of top and bottom attachments as
well, with top acting like left, bottom acting like right, y
acting like x, and height acting like width.

Resources

The following table defines a set of widget resources used by the
programmer to specify data. The programmer can also set the resource
values for the inherited classes to set attributes for this widget.
The codes in the access column indicate if the given
resource can be set at creation time (C), set by using
5SetValues (S), retrieved by using
5GetValues (G), or is not applicable (N/A).

5Form Resource Set
Name                  
Class                 
Type       
Default  
Access
5NfractionBase       
5CMaxValue           
int        
100      
CSG
5NhorizontalSpacing  
5CSpacing            
Dimension  
0        
CSG
5NrubberPositioning  
5CRubberPositioning  
Boolean    
False    
CSG
5NverticalSpacing    
5CSpacing            
Dimension  
0        
CSG

5NfractionBase

Specifies the
denominator used in calculating the relative position of a child
widget using 5ATTACH_POSITION constraints. The
value must not be 0.

If the value of a child's 5NleftAttachment (or
5NrightAttachment)
is 5ATTACH_POSITION, the position of the left (or
right) side of the child is relative to the left side of the 5Form and
is a fraction of the width of the 5Form. This fraction is the value of
the child's 5NleftPosition (or 5NrightPosition) resource
divided by the value of the 5Form's 5NfractionBase.

If the value of a child's 5NtopAttachment (or 5NbottomAttachment) is
5ATTACH_POSITION, the position of the top (or
bottom) side of the child is relative to the top side of the 5Form and
is a fraction of the height of the 5Form. This fraction is the value
of the child's 5NtopPosition (or 5NbottomPosition) resource
divided by the value of the 5Form's 5NfractionBase.

5NhorizontalSpacing

Specifies the offset for right and left attachments. This
resource is only used if no offset resource is specified (when
attaching to a widget), or if no margin resource is specified (when
attaching to the 5Form).

5NrubberPositioning

Indicates the default near (left) and top attachments for a
child of the 5Form. (Note: Whether this resource
actually applies to the left or right side of the child and its
attachment may depend on the value of the 5NstringDirection
resource.)

The default left attachment is applied whenever initialization or
XtSetValues leaves the child without either a left or
right attachment. The default top attachment is applied whenever
initialization or XtSetValues leaves the child
without either a top or bottom attachment.

If this Boolean resource is set to False, 5NleftAttachment and
5NtopAttachment
default to 5ATTACH_FORM, 5NleftOffset defaults to the
current x value of the left side of the child, and 5NtopOffset defaults to the current
y value of the child. The effect is to position the child
according to its absolute distance from the left or top side of the
Form.

If this resource is set to True, 5NleftAttachment and
5NtopAttachment
default to 5ATTACH_POSITION, 5NleftPosition defaults to a
value proportional to the current x value of the left side of
the child divided by the width of the 5Form, and 5NtopPosition defaults to a value
proportional to the current y value of the child divided by
the height of the 5Form. The effect is to position the child relative
to the left or top side of the 5Form and in proportion to the width or
height of the 5Form.

5NverticalSpacing

Specifies the offset for top and bottom attachments. This
resource is only used if no offset resource is specified (when
attaching to a widget), or if no margin resource is specified (when
attaching to the 5Form).

5Form Constraint Resource Set
Name                 
Class          
Type           
Default        
Access
5NbottomAttachment  
5CAttachment  
unsigned char  
5ATTACH_NONE  
CSG
5NbottomOffset      
5COffset      
int            
0              
CSG
5NbottomPosition    
5CAttachment  
int            
0              
CSG
5NbottomWidget      
5CWidget      
Widget         
NULL           
CSG
5NleftAttachment    
5CAttachment  
unsigned char  
5ATTACH_NONE  
CSG
5NleftOffset        
5COffset      
int            
0              
CSG
5NleftPosition      
5CAttachment  
int            
0              
CSG
5NleftWidget        
5CWidget      
Widget         
NULL           
CSG
5Nresizable         
5CBoolean     
Boolean        
True           
CSG
5NrightAttachment   
5CAttachment  
unsigned char  
5ATTACH_NONE  
CSG
5NrightOffset       
5COffset      
int            
0              
CSG
5NrightPosition     
5CAttachment  
int            
0              
CSG
5NrightWidget       
5CWidget      
Widget         
NULL           
CSG
5NtopAttachment     
5CAttachment  
unsigned char  
5ATTACH_NONE  
CSG
5NtopOffset         
5COffset      
int            
0              
CSG
5NtopPosition       
5CAttachment  
int            
0              
CSG
5NtopWidget         
5CWidget      
Widget         
NULL           
CSG

5NbottomAttachment

Specifies attachment of the bottom side of the child. It can
have the following values:

• 5ATTACH_NONE - Do not attach the bottom side
  of the child.
  
• 5ATTACH_FORM - Attach the bottom side of the
  child to the bottom side of the 5Form.
  
• 5ATTACH_OPPOSITE_FORM - Attach the bottom
  side of the child to the top side of the 5Form. 5NbottomOffset can be used to
  determine the visibility of the child.
  
• 5ATTACH_WIDGET - Attach the bottom side of
  the child to the top side of the widget or gadget specified in the
  5NbottomWidget resource. If
  5NbottomWidget is NULL,
  5ATTACH_WIDGET is replaced by
  5ATTACH_FORM, and the child is attached to the
  bottom side of the 5Form.
  
• 5ATTACH_OPPOSITE_WIDGET - Attach the bottom
  side of the child to the bottom side of the widget or gadget specified
  in the 5NbottomWidget
  resource.
  
• 5ATTACH_POSITION - Attach the bottom side of
  the child to a position that is relative to the top side of the 5Form
  and in proportion to the height of the 5Form. This position is
  determined by the 5NbottomPosition and
  5NfractionBase
  resources.
  
• 5ATTACH_SELF - Attach the bottom side of the
  child to a position that is proportional to the current y
  value of the bottom of the child divided by the height of the 5Form.
  This position is determined by the 5NbottomPosition and
  5NfractionBase
  resources. 5NbottomPosition is set to a
  value proportional to the current y value of the bottom of
  the child divided by the height of the 5Form.

5NbottomOffset

Specifies the constant offset between the bottom side of the
child and the object to which it is attached. The relationship
established remains, regardless of any resizing operations that occur.
When this resource is explicitly set, the value of 5NverticalSpacing is ignored.

5NbottomPosition

This resource is used to determine the position of the bottom
side of the child when the child's 5NbottomAttachment is set to
5ATTACH_POSITION. In this case the position of the
bottom side of the child is relative to the top side of the 5Form and
is a fraction of the height of the 5Form. This fraction is the value
of the child's 5NbottomPosition resource divided by
the value of the 5Form's 5NfractionBase. For example, if
the child's 5NbottomPosition is 50, the 5Form's
5NfractionBase is
100, and the 5Form's height is 200, the position of the bottom side of
the child is 100.

5NbottomWidget

Specifies the widget or gadget to which the bottom side of the
child is attached. This resource is used if 5NbottomAttachment is set to
either 5ATTACH_WIDGET or
5ATTACH_OPPOSITE_WIDGET.

A string-to-widget resource converter is automatically installed
for use with this resource. With this converter, the widget that is
to be the value of the resource must exist at the time the widget that
has the resource is created.

5NleftAttachment

Specifies attachment of the near (left) side of the child.
(Note: Whether this resource actually applies to the
left or right side of the child and its attachment may depend on the
value of the 5NstringDirection
resource.) It can have the following values:

• 5ATTACH_NONE - Do not attach the left side of
  the child. If 5NrightAttachment is also
  5ATTACH_NONE, this value is ignored and the child is
  given a default left attachment.
  
• 5ATTACH_FORM - Attach the left side of the
  child to the left side of the 5Form.
  
• 5ATTACH_OPPOSITE_FORM - Attach the left side
  of the child to the right side of the 5Form. 5NleftOffset can be used to
  determine the visibility of the child.
  
• 5ATTACH_WIDGET - Attach the left side of the
  child to the right side of the widget or gadget specified in the
  5NleftWidget resource. If
  5NleftWidget is NULL,
  5ATTACH_WIDGET is replaced by
  5ATTACH_FORM, and the child is attached to the left
  side of the 5Form.
  
• 5ATTACH_OPPOSITE_WIDGET - Attach the left
  side of the child to the left side of the widget or gadget specified
  in the 5NleftWidget resource.
  
• 5ATTACH_POSITION - Attach the left side of
  the child to a position that is relative to the left side of the 5Form
  and in proportion to the width of the 5Form. This position is
  determined by the 5NleftPosition and 5NfractionBase resources.
  
• 5ATTACH_SELF - Attach the left side of the
  child to a position that is proportional to the current x
  value of the left side of the child divided by the width of the 5Form.
  This position is determined by the 5NleftPosition and 5NfractionBase resources.
  5NleftPosition is set
  to a value proportional to the current x value of the left
  side of the child divided by the width of the 5Form.

5NleftOffset

Specifies the constant offset between the near (left) side of
the child and the object to which it is attached.
(Note: Whether this resource actually applies to the
left or right side of the child and its attachment may depend on the
value of the 5NstringDirection
resource.) The relationship established remains, regardless of any
resizing operations that occur. When this resource is explicitly set,
the value of 5NhorizontalSpacing is
ignored.

5NleftPosition

This resource is used to determine the position of the near
(left) side of the child when the child's 5NleftAttachment is set to
5ATTACH_POSITION. (Note: Whether
this resource actually applies to the left or right side of the child
and its attachment may depend on the value of the 5NstringDirection
resource.)

In this case the position of the left side of the child is relative
to the left side of the 5Form and is a fraction of the width of the
Form. This fraction is the value of the child's
5NleftPosition resource divided by the value of the
Form's 5NfractionBase. For example, if
the child's 5NleftPosition is 50, the 5Form's
5NfractionBase is
100, and the 5Form's width is 200, the position of the left side of the
child is 100.

5NleftWidget

Specifies the widget or gadget to which the near (left) side of
the child is attached. (Note: Whether this resource
actually applies to the left or right side of the child and its
attachment may depend on the value of the 5NstringDirection
resource.) This resource is used if 5NleftAttachment is set to
either 5ATTACH_WIDGET or
5ATTACH_OPPOSITE_WIDGET.

A string-to-widget resource converter is automatically installed
for use with this resource. With this converter, the widget that is
to be the value of the resource must exist at the time the widget that
has the resource is created.

5Nresizable

This Boolean resource specifies whether or not a child's
request for a new size is (conditionally) granted by the 5Form. If
this resource is set to True the request is granted if possible. If
this resource is set to False the request is always refused.

If a child has both left and right attachments, its width is
completely controlled by the 5Form, regardless of the value of the
child's 5Nresizable resource. If a child has a left
or right attachment but not both, the child's 5Nwidth is used in setting its width if
the value of the child's 5Nresizable resource is
True. These conditions are also true for top and bottom attachments,
with height acting like width.

5NrightAttachment

Specifies attachment of the far (right) side of the child.
(Note: Whether this resource actually applies to the
left or right side of the child and its attachment may depend on the
value of the 5NstringDirection
resource.) It can have the following values:

• 5ATTACH_NONE - Do not attach the right side
  of the child.
  
• 5ATTACH_FORM - Attach the right side of the
  child to the right side of the 5Form.
  
• 5ATTACH_OPPOSITE_FORM - Attach the right side
  of the child to the left side of the 5Form. 5NrightOffset can be used to
  determine the visibility of the child.
  
• 5ATTACH_WIDGET - Attach the right side of the
  child to the left side of the widget or gadget specified in the
  5NrightWidget resource. If
  5NrightWidget is NULL,
  5ATTACH_WIDGET is replaced by
  5ATTACH_FORM, and the child is attached to the right
  side of the 5Form.
  
• 5ATTACH_OPPOSITE_WIDGET - Attach the right
  side of the child to the right side of the widget or gadget specified
  in the 5NrightWidget resource.
  
• 5ATTACH_POSITION - Attach the right side of
  the child to a position that is relative to the left side of the 5Form
  and in proportion to the width of the 5Form. This position is
  determined by the 5NrightPosition and 5NfractionBase resources.
  
• 5ATTACH_SELF - Attach the right side of the
  child to a position that is proportional to the current x
  value of the right side of the child divided by the width of the 5Form.
  This position is determined by the 5NrightPosition and 5NfractionBase resources.
  5NrightPosition is
  set to a value proportional to the current x value of the
  right side of the child divided by the width of the 5Form.
  

5NrightOffset

Specifies the constant offset between the far (right) side of
the child and the object to which it is attached.
(Note: Whether this resource actually applies to the
left or right side of the child and its attachment may depend on the
value of the 5NstringDirection resource.)
The relationship established remains, regardless of any resizing
operations that occur. When this resource is explicitly set, the
value of 5NhorizontalSpacing is
ignored.

5NrightPosition

This resource is used to determine the position of the far
(right) side of the child when the child's 5NrightAttachment is set to
5ATTACH_POSITION. (Note: Whether
this resource actually applies to the left or right side of the child
and its attachment may depend on the value of the 5NstringDirection
resource.)

In this case the position of the right side of the child is
relative to the left side of the 5Form and is a fraction of the width
of the 5Form. This fraction is the value of the child's
5NrightPosition resource divided by the value of the
Form's 5NfractionBase. For example, if
the child's 5NrightPosition is 50, the 5Form's
5NfractionBase is
100, and the 5Form's width is 200, the position of the right side of
the child is 100.

5NrightWidget

Specifies the widget or gadget to which the far (right) side of
the child is attached. (Note: Whether this resource
actually applies to the left or right side of the child and its
attachment may depend on the value of the 5NstringDirection
resource.) This resource is used if 5NrightAttachment is set to
either 5ATTACH_WIDGET or
5ATTACH_OPPOSITE_WIDGET.

A string-to-widget resource converter is automatically installed
for use with this resource. With this converter, the widget that is
to be the value of the resource must exist at the time the widget that
has the resource is created.

5NtopAttachment

Specifies attachment of the top side of the child. It can have
following values:

• 5ATTACH_NONE - Do not attach the top side of
  the child. If 5NbottomAttachment is also
  5ATTACH_NONE, this value is ignored and the child is
  given a default top attachment.
  
• 5ATTACH_FORM - Attach the top side of the
  child to the top side of the 5Form.
  
• 5ATTACH_OPPOSITE_FORM - Attach the top side
  of the child to the bottom side of the 5Form. 5NtopOffset can be used to
  determine the visibility of the child.
  
• 5ATTACH_WIDGET - Attach the top side of the
  child to the bottom side of the widget or gadget specified in the
  5NtopWidget resource. If
  5NtopWidget is NULL,
  5ATTACH_WIDGET is replaced by
  5ATTACH_FORM, and the child is attached to the top
  side of the 5Form.
  
• 5ATTACH_OPPOSITE_WIDGET - Attach the top side
  of the child to the top side of the widget or gadget specified in the
  5NtopWidget resource.
  
• 5ATTACH_POSITION - Attach the top side of the
  child to a position that is relative to the top side of the 5Form and
  in proportion to the height of the 5Form. This position is determined
  by the 5NtopPosition and
  5NfractionBase resources.
  
• 5ATTACH_SELF - Attach the top side of the
  child to a position that is proportional to the current y
  value of the child divided by the height of the 5Form. This position
  is determined by the 5NtopPosition and 5NfractionBase resources.
  5NtopPosition is set
  to a value proportional to the current y value of the child
  divided by the height of the 5Form.
  

5NtopOffset

Specifies the constant offset between the top side of the child
and the object to which it is attached. The relationship established
remains, regardless of any resizing operations that occur. When this
resource is explicitly set, the value of 5NverticalSpacing is ignored.

5NtopPosition

This resource is used to determine the position of the top side
of the child when the child's 5NtopAttachment is set to
5ATTACH_POSITION. In this case the position of the
top side of the child is relative to the top side of the 5Form and is a
fraction of the height of the 5Form. This fraction is the value of the
child's 5NtopPosition resource divided by the value
of the 5Form's 5NfractionBase. For example, if
the child's 5NtopPosition is 50, the 5Form's
5NfractionBase is
100, and the 5Form's height is 200, the position of the top side of the
child is 100.

5NtopWidget

Specifies the widget or gadget to which the top side of the
child is attached. This resource is used if 5NtopAttachment is set to
either 5ATTACH_WIDGET or
5ATTACH_OPPOSITE_WIDGET.

A string-to-widget resource converter is automatically installed
for use with this resource. With this converter, the widget that is
to be the value of the resource must exist at the time the widget that
has the resource is created.

Additional Resources

5BulletinBoard Resource Set
Name                 
Class               
Type            
Default       
Access
5NallowOverlap      
5CAllowOverlap     
Boolean         
True          
CSG
5NautoUnmanage      
5CAutoUnmanage     
Boolean         
True          
CG
5NbuttonFontList    
5CButtonFontList   
5FontList      
dynamic       
CSG
5NcancelButton      
5CWidget           
Widget          
NULL          
SG
5NdefaultButton     
5CWidget           
Widget          
NULL          
SG
5NdefaultPosition   
5CDefaultPosition  
Boolean         
True          
CSG
5NdialogStyle       
5CDialogStyle      
unsigned char   
dynamic       
CSG
5NdialogTitle       
5CDialogTitle      
5String        
NULL          
CSG
5NfocusCallback     
5CCallback         
XtCallbackList  
NULL          
C
5NlabelFontList     
5CLabelFontList    
5FontList      
dynamic       
CSG
5NmapCallback       
5CCallback         
XtCallbackList  
NULL          
C
5NmarginHeight      
5CMarginHeight     
Dimension       
0             
CSG
5NmarginWidth       
5CMarginWidth      
Dimension       
0             
CSG
5NnoResize          
5CNoResize         
Boolean         
False         
CSG
5NresizePolicy      
5CResizePolicy     
unsigned char   
5RESIZE_ANY  
CSG
5NshadowType        
5CShadowType       
unsigned char   
5SHADOW_OUT  
CSG
5NtextFontList      
5CTextFontList     
5FontList      
dynamic       
CSG
5NtextTranslations  
5CTranslations     
XtTranslations  
NULL          
C
5NunmapCallback     
5CCallback         
XtCallbackList  
NULL          
C

5Manager Resource Set
Name                   
Class                  
Type               
Default               
Access
5NbottomShadowColor   
5CBottomShadowColor   
Pixel              
dynamic               
CSG
5NbottomShadowPixmap  
5CBottomShadowPixmap  
Pixmap             
5UNSPECIFIED_PIXMAP  
CSG
5Nforeground          
5CForeground          
Pixel              
dynamic               
CSG
5NhelpCallback        
5CCallback            
XtCallbackList     
NULL C
5NhighlightColor      
5CHighlightColor      
Pixel              
dynamic               
CSG
5NhighlightPixmap     
5CHighlightPixmap     
Pixmap             
dynamic               
CSG
5NinitialFocus        
5CInitialFocus        
Widget             
dynamic               
CSG
5NnavigationType      
5CNavigationType      
5NavigationType   
5TAB_GROUP           
CSG
5NshadowThickness     
5CShadowThickness     
Dimension          
dynamic               
CSG
5NstringDirection     
5CStringDirection     
5StringDirection  
dynamic               
CG
5NtopShadowColor      
5CTopShadowColor      
Pixel              
dynamic               
CSG
5NtopShadowPixmap     
5CTopShadowPixmap     
Pixmap             
dynamic               
CSG
5NtraversalOn         
5CTraversalOn         
Boolean            
True                  
CSG
5NunitType            
5CUnitType            
unsigned char      
dynamic               
CSG
5NuserData            
5CUserData            
XtPointer          
NULL                  
CSG

Composite Resource Set
Name               
Class              
Type         
Default  
Access
5Nchildren        
5CReadOnly        
WidgetList   
NULL     
G
5NinsertPosition  
5CInsertPosition  
XtOrderProc  
NULL     
CSG
5NnumChildren     
5CReadOnly        
Cardinal     
0        
G

Core Resource Set
Name                           
Class                          
Type            
Default               
Access
5Naccelerators                
5CAccelerators                
XtAccelerators  
dynamic               
N/A
5NancestorSensitive           
5CSensitive                   
Boolean         
dynamic               
G
5Nbackground                  
5CBackground                  
Pixel           
dynamic               
CSG
5NbackgroundPixmap            
5CPixmap                      
Pixmap          
5UNSPECIFIED_PIXMAP  
CSG
5NborderColor                 
5CBorderColor                 
Pixel           
XtDefaultForeground   
CSG
5NborderPixmap                
5CPixmap                      
Pixmap          
5UNSPECIFIED_PIXMAP  
CSG
5NborderWidth                 
5CBorderWidth                 
Dimension       
0                     
CSG
5Ncolormap                    
5CColormap                    
Colormap        
dynamic               
CG
5Ndepth                       
5CDepth                       
int             
dynamic               
CG
5NdestroyCallback             
5CCallback                    
XtCallbackList  
NULL                  
C
5Nheight                      
5CHeight                      
Dimension       
dynamic               
CSG
5NinitialResourcesPersistent  
5CInitialResourcesPersistent  
Boolean         
True                  
C
5NmappedWhenManaged           
5CMappedWhenManaged           
Boolean         
True                  
CSG
5Nsensitive                   
5CSensitive                   
Boolean         
True                  
CSG
5Ntranslations                
5CTranslations                
XtTranslations  
dynamic               
CSG
5Nwidth                       
5CWidth                       
Dimension       
dynamic               
CSG
5Nx                           
5CPosition                    
Position        
0                     
CSG
5Ny                           
5CPosition                    
Position        
0                     
CSG

Now if you've made it this far and not realised, this isn't actually a new widget for HTML5 its actually just a widget from the late 1980s called XmForm which remains the most powerful layout manager I've personally ever come across in a widget tool kit.

Why this silly post then? Well its sort of to make the point that client side frameworks are a "solved problem" and rather than heading out are re-inventing wheels we should think about what is actually new.

So the differences with XWindows and HTML5 are what? Putting aside the syntax and URIs via XAtom et al what are the real architectural differences from a client side framework perspective? I'd argue that the difference is sophistication. HTML5 is in its infancy but should we expect widget sets and libraries to be created, layout managers and other elements... of course we should.

So rather than creating all this stuff from scratch lets go back to the future to when client side interfaces had to be rich and had to handle huge complexities and learn from those frameworks rather than thinking that client side development is a new challenge for IT that needs lots of debate.

What ever happens it should be based around the principles of HMVC (Hierarchical Model View Controller) and should learn the lessons of GTK, Swing, Motif, X-Windows and the like.

Lets port XmForm to HTML5 rather than try and create everything again from the base up.

Technorati Tags: SOA, Service Architecture

There is no HR/Business divide, which is why its IT's fault

The IT/Business divide is something that exists in most businesses I've worked with. I think it comes from a few different drivers, one of which being that IT is often the smartest set of folks in the room academically if not socially. But one piece I can't agree with is that the fault for the divide lies on both sides.

Lets flip away from IT for a moment and concentrate on other "support" parts of the organisation. HR and Finance. These aren't the front-line of the business but they are critical support functions. Now I've regularly heard people in the business moan about Finance being too conservative or too controlling but I've never heard people talk about a Finance/Business divide or that the CFO is disconnected from the business. The perspective might be that Finance has a different view on the current opportunities or issues but not that the business and Finance are disconnected. HR even more so, the HR Director who is disconnected from their business is a fired HR director.

In IT however I've regularly seen CIOs who are disconnected from the business and seen architecture communities who have said classic phrases like "it doesn't matter what the business wants, if we say its not going in, its not going in". IT continues to talk technology rather than business and optimise things (programming languages) that add zero business benefits. IT regularly bleats "The business must realise how important this is" rather than actually working out what is important to the business.

The business/IT divide is the fault of IT because IT doesn't make the effort to communicate the value in the language of the business its like the worst kind of tourist who thinks that shouting louder is better than learning the local language.

Its time for IT to stop looking inwards on optimising wheels and start focusing on how to communicate about IT with the business in their own language.

Technorati Tags: SOA, Service Architecture

MDM, SOA and BPM - making processes simple

BPM is once again a hot topic. It seems several years ago where I said "if you want to get enterprise cash, learn BPEL"... in fact it was 5 years ago! However BPM really hasn't delivered on the promises and that is for three reasons

1) The Promises were too big
2) The implementations were too complex

3) BPEL rapidly became a Visual COBOL approach

Now I've said before that BPM screws up SOA and that SOA makes BPM simple, I'll stick with that and I'll now raise another piece in conjunction with SOA and MDM. This is actually a way to make BPM work more effectively, more simply and reduce the issues around elements such as process [de|]hydration. Namely that if you are in an area where BPM is the best implementation approach for a specific service's capability then using MDM helps to make its implementation simpler as you can work on key exchange rather than on content exchange.

Rather than BPM folks worrying about the schemas and exchange of core information that is left to MDM (where it belongs) and the SOA pieces handles the business domains part to make sure processes have clear boundaries and can be well managed.

Technorati Tags: SOA, Service Architecture