1. Generated header file names unification crossing foreign orbs. I
don't call this "portability" to avoid confusion with next issue. For
this unification, I said, I was just "guessing" why folks defined C++
mapping didn't put this seemingly trivial thing in the specification.
2. Extending CORBA specification to support generic application code
portability. As you are just iterating your original arguments, I also
will iterate mine briefly (for detail, see previous post):
* OMG is not a right organization to head this effort. It should go to
Opengroup, ISO, IEEE, etc..
* It damages CORBA.
> Well, when I say a software system, CORBA is a small part of it, that
> only enables transparent communication among its objects and access
> domain services in a uniform manner.
> But it is not my complete system. Right? CORBA then becomes very small
> part of my overall system. By that what I mean is that object
> communication is not the end am looking for. Am looking for development
> and deployment of those objects as well, over heterogeneous
> environment.
> Here comes one of the most trivial and irritating problem CORBA
> offers, name of stubs and skeletons files, is not portable.! No other
> words than its ridiculous, then that vendors didnt suggest this
> themselves?
> Dr. Schmidt has correctly suggested to correct this issue.
> > If used to implement
> > client logic or servant logic, then, they are out of the scope of
> > CORBA, and their portability is not an issue of CORBA.
> I never said that it is within scope of CORBA currently. But if I go by
> general definition of "middleware"
> ------start
> A "middleware system" (a.k.a. computing infrastructure) constitutes a
> set of services that aim at facilitating the development of distributed
> applications in heterogeneous environments. The primary objectives of
> middleware are to foster APPLICATION PORTABILITY and distributed
> application component interoperability. At least conceptually, the
> "middleware layer" comprises a layer below the application and above
> the operating system and network substrate. Common middleware platforms
> include CORBA, DCOM, Java RMI, MQSeries, and MSMQ et al.
> ----end
> Repeat "application portability". Lets forget about all middle
> wares other than CORBA (as they don't resolve so many complex issues
> that corba resolves). So how does corba resolves "application
> portability". When the vendors are stuck at "non portability" of
> stubs and skeletons (use less from application programmers
> perspective).
> Let me put this way, how does vendors provide corba implementation for
> different platforms? I am sure they would have abstracted a layer
> wherein they would be handling all platform specific issues. At least
> ACE (TAO) has open implementation. And this is better design as well.
> So what am suggesting is make this layer available to application
> programmer as well, as a standard. So that CORBA becomes a true
> middleware by providing complete portability.
> > Unlike Java, .NET, etc,. CORBA itself is not "yet another uniform"
> > programming environment/platform, but a "middleware" infrastructure
> > to "mediate" business logics distributed over heterogeneous
> > environments.
> J2EE / .NET too provide middleware infrastructure. And to a large
> extend their success can be attributed to uniform programming
> environment and supporting tools that are easy to develop, at least
> compared to corba tools!
> CORBA can be made to address this aspect as well.
> > Firstly, there had been many attempts to standardize portable OS
> > interfaces in history, seen in the efforts of UI (unix international),
> > POSIX, OSF and X/Open (the two are now OpenGroup), etc.. Attempts of
> > having similar thing crossing unix and windows are not rare either,
> > including POSIX API (or its C++ variant) on Windows, WIN32 API or MFC
> > for unix, and so on, not mention open source contribution from GNU and
> > others. OMG is only one middleware standard body (certainly, OMG also
> > has many service and domain specific standards and MDA). To standardize
> > portable OS interface, OMG has almost no influence and zero credit
> > comparing to OpenGroup, ISO, IEEE and even ANSI, etc.. Therefore, even
> > if people wanted to reinvent-the-wheel, OMG is not the right
> > organization to head this effort.
> I never meant to let OMG standardize os layer. After all OMG is not
> trying to address that space at all. It is putting all the efforts to
> standardize middleware, so that completely interoperable and portable
> systems may be developed.
> Mind you portable! Again. And this can be achieved as demonstrated by
> at least one orb vendor.
> > Secondly, it is easy to construct a portable OS layer which covers
> > selected system functions enough to implement a few specific ORBs and
> > applications. NEVERTHELESS, contrary to what you thought, it is
> > non-trivial at all to generalize this, by extending CORBA, to an
> > universal portable application programming platform. If it was as easy
> > and useful as you thought, why it hasn't been addressed for years,
> > and has to wait the hero OMG, who was said to out smart OpenGroup,
> > ISO, IEEE, ANSI folks just because who happen to have a magic thing
> > called CORBA? Even if excluded database and message middleware
> > abstractions and so on, and only limited this portable layer to cover
> > OS system functions, it would still not be a trivial undertaking to
> > have most mainstream flavor unix, windows and various RTOS (not merely
> > socket and thread parts) covered by one Swiss army knife which could be
> > reasonably function complete (not merely a small common subset),
> > efficient (it is no than an impl. issue!!), scaleable (in sense of
> > dynamic and static), consistent, extendable, intuitive and clear-cut,
> > ... and so on. Some of the above requirements are even mutual
> > exclusive. For instance, function complete (even if not 100%),
> > simplicity, lightweight and efficient together may prohibit
> > portability.
> Am not suggesting to make uniform os layer. But provide to application
> programmer uniform layer.
> > Thirdly, extending CORBA specification (or some other OMG
> > specifications) to based on a language (C++) specific design would
> > immediately bring damages to the consistency of the CORBA architecture,
> > such as language neutral and consistent memory management rule defined
> > by IDL-to-C++ mapping.
> Why How?? Even now we do have language specific mapping specification.
> > An alternative is using local object IDL to
> > define such abstraction. Nevertheless, even if it could be accepted
> > outside OMG community, it was likely to have performance penalty, as a
> > lesson we have learnt from portable interceptor.
> Things can always be designed in a better way. I mean vendors should
> use that knowledge and contribute as per their exp for the development
> of such a standard than allowing again to develop non portable
> application, and incur cost in when needed for migration, re-deployment
> etc.
> > Again, pls consider,
> > if we could easily and consistently extend CORBA or another OMG
> > specifications to include what you suggested, why would it wasn't
> > there in the original OMA or CORBA architecture? We are out smart our
> > OMG initiators?
> Ah not like that. Everything has a start, and we know a thing finally
> shapes up in iteration. Not waterfall. Right?
> > As I said, it was my GUESS. I don't assume I am out smart those folks
> > defined the C++ mapping, and would like to GUESS their original
> > consideration of not specifying this. Pls think about non-trivial
> > cases. For instance, how would the specification avoid generated head
> > file names to conflict with existing system and library header files.
> > How would the specification ensure the generated header file name and
> > extension name are valid on all mainstream platforms (some platforms
> > have strict name length limitation).
> How does it currently addresses using c++ key words in idl?
> Point is we need to first do correct things and than address things
> that are now behaving wrong because of this correction. Provide some
> solution for that.
> > What would be the best practice to
> > partition generated content in header files (e.g. all in one jumbo
> > header file, or partitioned to multiple header files). If an IDL file
> > includes other IDL files, should one jumbo header file be generated, or
> > one (or multiple) header file(s) for each of the original and included
> > IDL files?
> How much does that affects the user?
