Re: [www-vrml] vrml/x3d in frames

["George Birbilis" <birbilis@kagi.com>]

(sorry for the long e-mail below...)

>Another good example of the benefits of COM support.

btw my Plug components were originally made as VCL (Visual Component
Library) components for Delphi: those are very nice in that they get
compiled inside your .EXE, no need to install stuff to the users machine,
can just run your EXE from CD etc. However VCL components aren't a binary
component standard as ActiveX controls. That is they're practically
source-code components since I have to provide builds of those for every
Delphi version (@#$%@#%@#). Luckily I don't need to pass on the source code
to the users to compile their Delphi app, I pass to them compiled libraries
(but unfortunately different ones for every Delphi version, 3,4,5,6,7 are
lot of versions to support)

whereas my ActiveX version of the components are wrappers that contain the
VCL version (compiled into the ActiveX DLL [.OCX file - called an inprocess
COM server cause it gets loaded and runs inside the process space of the
container application - the client]). They need to be installed first to the
users machine (I might find some trick to circumvent that need in the future
though) since ActiveX control clients check the registry to find where a
component is installed (they ask for that component by progID [name] or by
clsIS [class id, a Globally Unique Identifier / GUID - a statistically
unique number]).

This means no run from CD without installing some stuff to the users machine
first (and the user needs to have admin priviledges I think). However I make
ONLY one build and it runs in any container that supports ActiveX, e.g.
PowerPoint, MATLAB, VB, LabView, Internet Explorer, in .NET apps etc. (even
in Delphi apps since it can host ActiveX controls in your Delphi forms).
Compare this to the hell of providing VCL controls for every different
Delphi version.

No wonder Delphi8 now is ONLY for .NET and doesn't build Win32 applications
anymore (users have to use versions up to Delphi7 for building Win32
applications). That will mean is I make .NET versions of my components with
Delphi8 they'll run in all future Delphi versions (including all other .NET
apps). And I won't need to use ActiveX controls then and pass through the
COM-.NET interoperability layer (plus my stuff will be portable to
Linux/Unix/MacOS-X using "mono")

btw, ActiveX controls are a different breed than .NET controls. They don't
need some runtime to run into, they're binary components that run inside
their host process (DLLs - dynamically linked libraries). COM/OLE/ActiveX
was and is still a very powerful technology and will definitely be used
under the hood of Microsoft's .NET implementation on Windows for some years.
Similar technologies like XPCOM may be used in mono under the hood, haven't
checked.

>I know it's not cross platform, but it does give access to OS underlying
>services, like any kind of IPC schemes, from DDE to virtual shared memory,
>or channels, etc ...

well COM as a spec, is cross-platform (e.g. implemented on WindowsCE for
various RISC-based CPUs) and the easily portable XPCOM is following closely
the COM spec for example (btw Microsoft's COM is implemented on UNIX and
parially implemented on MacOS but that one is mostly used internally by MS
software for Mac - Software like KATIA [CAD for aerospace etc.] if I
remember well use their own implementation of COM and OLE controls specs)

>I don't mean I'm not interested in Linux, MacOS, BeOS, Amiga, CP/M or
>else,I certainly don't say it should be in the spec, but ... If some plugin
> developpers are listening to this thread ... Herman, Tony ?

to talk between platforms, HTTP and TCP/IP is OK
to call procedures etc. RPC is OK
to call OOP methods ORPC-style mechanisms are OK
to play it nice with firewalls use SOAP
for fast stuff use UDP but will have problem with firewalls etc.

> Set the VR plugins free from Browsers - build communicating applications -
> why do we need IE sandBox when it's possible to open HTML pages
> *inside* 3D
> plugin ? - We need shared VR servers and protocols, not Hyper Text
> (HTTP)servers - etc ...

we need interoperation with existing component/container technologies:
* ActiveX controls and possibly OLE controls too (older spec than ActiveX,
but richer interaction that ActiveX controls, tighter integration with
container using menu negotiation etc., ActiveX is a subset of OLE with some
additions for Internet notions)
* Netscape plugins
* scriptable Mozilla plugins (they recently published some specs on that)
* JavaBeans
* Qt (TrollTech's portable component framework) components
etc.

can't have 3D/VR live on its own and ignore the environments people use
today

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
George Birbilis <birbilis@kagi.com> [Microsoft MVP J#]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ QuickTime VCL and ActiveX controls (for PowerPoint/VB/Delphi etc.)
+ Plugs VCL and ActiveX controls (InterProcess/Internet communication)
+ TransFormations, VB6 forms to ASP.net WebForms convertion
http://www.kagi.com/birbilis
+ Robotics
http://www.mech.upatras.gr/~robgroup
........................................................................

-------------------------------------------------------------------------
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html