Issue 2941: Is GIOP 1.x sustainable any more? (interop)
Source:  (Mr. Adrian St. John, )
Nature: Uncategorized Issue
Severity: 
Summary: Is GIOP 1.x really sustainable any more?
We've got implementation nightmares because:

* Features haven't been thought through properly
  eg Fragment in 1.1, BiDir in 1.2

* Simple backwards compatibility is being lost
  eg ReplyHeader v1.2 has fields in completely different places to
  previous versions, albeit for very good reasons.

* The TypeCode CDR version problems

* Not enough information in certain messages
  eg MessageError can't indicate which message may have caused a
  problem, and certainly can't describe in what way there was an error.

Resolution: see above
Revised Text: 
Actions taken:
September 23, 1999: received issue
May 13, 2002: closed issue
Discussion: 
Changes of this magnitude cannot be cannot be done by an RTF and require
an RFP.
End of Annotations:=====
ate: Thu, 23 Sep 1999 14:44:17 +0100
From: "Adrian St. John" <adrian@realobjects.co.uk>
To: interop@omg.org
Subject: Is GIOP 1.x sustainable any more?
Message-Id: <37EA2EB1182.012FADRIAN@granite>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.25.06
Content-Type: text/plain; charset=US-ASCII
X-UIDL: d94ffe8a307bddba4a7464b3fab4d221

Hi,

Is GIOP 1.x really sustainable any more?
We've got implementation nightmares because:

* Features haven't been thought through properly
  eg Fragment in 1.1, BiDir in 1.2

* Simple backwards compatibility is being lost
  eg ReplyHeader v1.2 has fields in completely different places to
  previous versions, albeit for very good reasons.

* The TypeCode CDR version problems

* Not enough information in certain messages
  eg MessageError can't indicate which message may have caused a
  problem, and certainly can't describe in what way there was an
error.

What I suggest is that we get GIOP 1.2 out the door (with whatever
hack
solution is required for BiDir to work with Fragment), and then take a
clean break to GIOP 2.0.

Since the original specification of GIOP clearly implies that we would
produce major updates, is there any reason why the problems we're
facing
now don't amount to enough to warrant a major version change? If not,
what would it take for us to go for a major version change?

We've learnt a lot from developing GIOP to its current stage, and like
all good designers we've (hopefully) learnt from our mistakes, so we
can
design a consistent, useful protocol that can be extended in an easier
manner.

Adrian St. John

--
Adrian St.John (adrian@realobjects.co.uk)
Real Objects Ltd. 
http://www.realobj.demon.co.uk