Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Novell (NOVL) dirt cheap, good buy? -- Ignore unavailable to you. Want to Upgrade?

To: Jim McCormack who wrote (21460)	3/30/1998 3:20:00 AM
From: Scott C. Lemon	Read Replies (1) \| Respond to of 42771

Hello Jim, > Java Spec Compliance is "Step One" > > I would like to discuss this topic to get your perspective.... I'll try ... > Being 1.1.5 compliant is "OK" but surely you would agree that one > could improve upon the spec and add new features and enhancements > to improve the product ..... With Java there is a very useful effort to keep some level of compatibility. There is the ability to provide "native methods" which provide platform specific extensions to the environment - without breaking the compatibility. If a developer knows that they are using "native methods" they know that they might not run on other platforms. > Look at SQL - that has an ANSI spec. Almost every SQL vendor (Orcl, > MS, IBM, Sybase) have a set of extensions to the spec to make the > products more appealing to different consumers. I think this is more a question to the customer! If the customer chooses to implement "non-standard" extensions by using a product from vendor A, then they must understand that they are investing in Vendor A - not the standard. This is much like the current misunderstandings in application software investments. IMHO, customers should be investing in applications based on standard protocols ... not proprietary APIs. If you look at the current Windows model, Microsoft has convinced everyone to invest more and more into their proprietary Win32 APIs by buying more and more Win32 applications. This ties the customer to Microsoft and Windows and makes the cost of change in the future very high. Investing in an API is not investing in your network ... investing in standard protocols is investing in your network. Java ... investing in Java means investing in a cross platform application environment. You can run Java on Windows, and probably will, but it gives the customer the choice in the future to decide what OS they want to run on. It also gives the customer the lever that they need to keep vendors honest and providing quality, and timely, solutions. If a customer invests in Java they can keep running Windows ... but they can also migrate if they choose to! > SQL and JAVA products are not commodities and they compete on > factors beyond price... what good is it to have 10 people produce > exactly the same product? Sure - some base level of functionality > should be ensured - thats where the spec comes in.... a minimum. I agree ... people will add features ... but as a customer I would be pushing for evolving standards ... not proprietary dead-ends! > I want as many features as I can get and then I'll choose the > vendor with the best set to meet my applications needs. But you might end up trapped with an implementation that is entirely dependent on a proprietary extension. When the vendor you chose can't deliver you are in a hard place! I don't know how many customers that I've talked to that have realized how trapped they are with proprietary Win32 investments ... > I welcome all the extensions - after all here do you think they get > the next round of features for future spec releases? I'll agree with this ... but I would be cautious on how quickly I adopt proprietary extensions unless I really feel comfortable with the vendor and their ability to deliver on quality and time. I tend to try and evaluate contingencies and know that there is no end to standards ... but you want to ensure that the extensions are published and made available to other vendors ... simple "second sourcing" concepts ... > Novell is in a good position with a server side Java product. Have > to wait and see how things play out. All Novell can do is implement > the spec and hope that developers choose them for the back end. ;-) I'm not one for wait and see ... and I'm not sure that I entirely agree with your position here. But it is too early in my experimentation and analysis to make my mind up ... I'll know more in the next several months ... > Those companies that control and backend and the frontend will no > doubt add features to the spec and leverage the position they hold > by allowing developers to implement new extensions on the frontend > products and supporting them on the backend products they produce. If software companies stray too far they will not have the cross platform benefits of Java. If customers invest in Java apps that use platform specific behaviors then they will be investing in the platform ... not Java. I believe that both of these are bad things. To me, much of this conversation is equivalent to talking about app developers writing to proprietary AMD extensions to the Pentium instruction set. This might make the app run better on an AMD chip, but eliminates the ability to run on the real Intel product! > Novell has to align itself with a Frontend/Backend provider - > Netscape/Oracle - ... which it has ... Novonyx and now a 5 user Oracle bundle ... > and extend the spec in partnership to match features with the MS > extensions. If you do not match features you will be left > behind.... SQL evolution has taught us that...... Database > Replication for instance was not part of the original spec but it > is now and all vendors support it.... It started as a proprietary > extension. I believe that there are still ways to extend the functionality by layering services on top of the base JVM. > Specs are a snapshot - Dated as soon as they are written - the > market place demands innovation - if a new set of code is added as > an extension that solves a critical problem - the spec evolves... Agreed ... as long as the extensions are offered up to standards committees and the public. But I still believe that a customer that invests their money in proprietary extensions, where a vendor refuses to publish complete documentation, is taking a risk that must be evaluated. Microsoft will do anything now to pull customers further down the dead-end Windows road. Proprietary APIs are the way to prevent the customer of having any choice. I like having a choice because it forces a vendor to offer more! If they don't deliver ... I have a choice I can, but do not have to, make. > That is a good thing! I like companies that push limits! Scott C. Lemon