[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [www-vrml] vrml/x3d in frames
Sure we gotta use the systems in place today
But why do we as vrml/x3d editors have to go through all this code
programming?
To do the same sort of functions in html does not take as much programming,
in fact its stupidly easy
An ease of usage is whats is needed
Designers don't want to program and vice versa
All your examples include a massive learning curve, especially for
enthusiasts like say.. Lens kid :D
we are following trends that as we know flitter in microsofts ete
Microsoft is a fickle company, when it comes to their own api's
How many technologies have they released and then abandoned
> -----Original Message-----
> From: owner-www-vrml@web3d.org
> [mailto:owner-www-vrml@web3d.org] On Behalf Of George Birbilis
> Sent: October 2, 2004 4:15 AM
> To: www-vrml@web3d.org
> Subject: Re: [www-vrml] vrml/x3d in frames
>
> (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
>
>
-------------------------------------------------------------------------
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html