Kylix is not KDE's ace-in-the-hole, it's Borland's. Kylix apps will run on top of KDE, GNOME, or no desktop at all. It has no dependency on KDE at all.
Both are copyrighted. If the assertion that a developer cannot look at the stolen source are true (without exposing a product to jeopardy), then wouldn't someone who's done MFC development and looked at the MFC source be at risk in the same way? In both cases, MS could alledge that its copyrighted code has been copied. Anyone care to explain this?
KDE could get around this if they'd build a version on Qt Embedded instead of Qt for X. Qt Embedded has everything that windows has and X lacks: no context-switching sluggishness, anti-aliased fonts, etc.
You've omitted the most important such standard of all: UPnP (www.upnp.org). You point out that the Jini classes have crummy licensing terms. UPnP doesn't require licensing anybody's classes but rather is based on open protocols.
Unlike Jini, UPnP description XML can be discovered and parsed at runtime, whereas using another Jini device requires that you know the signatures of its interfaces at runtime.
And yes there's an open source implementation (upnp.sourceforge.net).
Regarding loss of foothold: I think they still have at least that, but not much more. Delphi and BCB enjoy I think ~5-10% of the windows dev tools market (if I recall a survey correctly).
I think Borland does "have the stuff" to make it happen. Not the least part of which is a balance sheet you could choke a horse with ($230 M in cash).
Once a device's type is known (e.g. printer, camera, HVAC system, etc.), you know how to invoke it's commands because all devices of a given type implement the same command set.
A UPnP device makes an API available by using the control protocol of UPnP. UPnP control commands are invoked over the network using SOAP. See the UPnP specs at www.upnp.org for details.
You are exactly right. UPnP is Microsoft's response to Sun's Jini(1).
The difference is this: Jini(1) is proprietary in that it requires all participants to be running on a Java(1) Virtual Machine. Last time I checked, one had to pay a royalty to Sun to use their Jini(1) classes to create a Jini(1) device. I don't know if this has changed.
UPnP on the other hand is based on protocols. Anyone can participate in UPnP just by implementing the required protocols.
Another difference is that Microsoft took a much more pro-active approach to getting the ball rolling by defining various standard device types and service types (which are described with XML). There's a lot of stuff in the works, although I don't recall exactly what my NDA permits me to talk about, so I better not say anything about it.
We were actually working on an implementation of UPnP for Linux when we got word that Intel was going to release an implementation, at which time we shelved it.
(1) Third party marks and brands are the property of their respective holders.
Slashdot Mirror
Kylix is not KDE's ace-in-the-hole, it's Borland's. Kylix apps will run on top of KDE, GNOME, or no desktop at all. It has no dependency on KDE at all.
Both are copyrighted. If the assertion that a developer cannot look at the stolen source are true (without exposing a product to jeopardy), then wouldn't someone who's done MFC development and looked at the MFC source be at risk in the same way? In both cases, MS could alledge that its copyrighted code has been copied. Anyone care to explain this?
KDE could get around this if they'd build a version on Qt Embedded instead of Qt for X. Qt Embedded has everything that windows has and X lacks: no context-switching sluggishness, anti-aliased fonts, etc.
You've omitted the most important such standard of all: UPnP (www.upnp.org). You point out that the Jini classes have crummy licensing terms. UPnP doesn't require licensing anybody's classes but rather is based on open protocols.
Unlike Jini, UPnP description XML can be discovered and parsed at runtime, whereas using another Jini device requires that you know the signatures of its interfaces at runtime.
And yes there's an open source implementation (upnp.sourceforge.net).
Regarding loss of foothold: I think they still have at least that, but not much more. Delphi and BCB enjoy I think ~5-10% of the windows dev tools market (if I recall a survey correctly).
I think Borland does "have the stuff" to make it happen. Not the least part of which is a balance sheet you could choke a horse with ($230 M in cash).
Kylix is not "working with KDE." Kylix and Kylix-created apps will run on both Gnome and KDE.
As far as a Borland role in this KParts/Bonobo interoperability I have no idea, but I'm sure they'd like to see it.
Oops, I meant this to be formatted like this:
>>except it's supposed to work with Intel
>> hardware only
No, UPnP is not tied to Intel hardware in any way. See www.upnp.org.
>>except it's supposed to work with Intel >> hardware only No, UPnP is not tied to Intel hardware in any way. See www.upnp.org.
Once a device's type is known (e.g. printer, camera, HVAC system, etc.), you know how to invoke it's commands because all devices of a given type implement the same command set.
A UPnP device makes an API available by using the control protocol of UPnP. UPnP control commands are invoked over the network using SOAP. See the UPnP specs at www.upnp.org for details.
You are exactly right. UPnP is Microsoft's response to Sun's Jini(1).
The difference is this: Jini(1) is proprietary in that it requires all participants to be running on a Java(1) Virtual Machine. Last time I checked, one had to pay a royalty to Sun to use their Jini(1) classes to create a Jini(1) device. I don't know if this has changed.
UPnP on the other hand is based on protocols. Anyone can participate in UPnP just by implementing the required protocols.
Another difference is that Microsoft took a much more pro-active approach to getting the ball rolling by defining various standard device types and service types (which are described with XML). There's a lot of stuff in the works, although I don't recall exactly what my NDA permits me to talk about, so I better not say anything about it.
We were actually working on an implementation of UPnP for Linux when we got word that Intel was going to release an implementation, at which time we shelved it.
(1) Third party marks and brands are the property of their respective holders.