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: Paul Fiondella who wrote (30261)	2/11/2000 12:20:00 PM
From: Scott C. Lemon	Respond to of 42771

Hello Paul, You are exactly on track as we dig deeper! ;-) This is a standard mode of operation for Microsoft, and I have to say that it makes complete sense for any company to learn from this strategy as it is a very good one ... and one used by numerous successful companies. The game is "abstraction" ... > You also say that Novell supports ADSI. Do you mean that a > developer can write applications that use ADSI and have them run on > a Netware server? No. Novell has not decided to port the ADSI APIs to the NetWare platform ... yet. Novell always tends to move slowly in providing their developer community with standardized APIs for development. They recently added the WinSOCK2 APIs to NetWare with NetWare v5 and the ODBC-like APIs are supposed to be in NetWare v5.1 ... but I haven't verified that yet. Also, they are often incomplete ... but that's another story. In short, I know of no announcements to provide the ADSI APIs on NetWare ... BUT, Novell has developed an "ADSI Provider" which allows developers to write applications to ADSI that access NDS! > Or are you saying that to write using ADSI you have locked yourself > into a Windows environment? For now, this is the case. Just like if you wrote to any of the Windows APIs ... you have locked yourself into Windows. Just like if you write to Linux APIs then you have locked yourself into Linux, and on and on ... It's really not as much the writing to the APIs that "locks you in" as much as the "binary" application that you compile and build. > The next level of this question would be, is it as easy to use ADSI > and write an application that uses NDS, e-directory etc. etc. as it > is to use AD? Yes! Because of the ADSI provider developed by Novell, you can access NDS via the ADSI APIs ... > Or are there quirks? Well, this is something that I would have to ask an experience ADSI/NDS developer. There could be quirks, depending on how Novell wrote the ADSI Provider ... if they did a good job, then it should be clean. > "One of the most familiar open programming APIs is Open Data Base > Connectivity (ODBC). ODBC provides open interfaces for relational > databases, thus allowing developers to write applications and tools > that work with any database that supports ODBC. Because of the > thriving ODBC development community, every major relational > database now supports ODBC. ADSI is the equivalent of ODBC for > directory services. " > > That is what Microsoft says. Is it true? Yes ... this is the "abstraction" strategy that Microsoft has followed (quite successfully) for years. When they observe competing standards in the industry, they look at how they can provide an "umbrella" set of APIs on Windows which can accommodate all of them. They have done this with the NetWare, Mail, Database, etc. They keep enhancing the Windows offering to include APIs for developers which support numerous back-end systems. > Is ADSI open and extensible by reference to a standards committee? No standards committee that I know of. It is a set of APIs specific to the Windows platform. But the APIs are documented, as is the "provider" interface ... so both sides. This is how Novell developed their NDS Provider. > Who controls how well ADSI works with LDAP or NDS? This is up to the NDS Provider developer, and the LDAP Porivder developer. Novell wrote the NDS one, and I think that Microsoft wrote the LDAP Provider. But there is nothing that I know of which would limit the addition of other directory service providers. Someone could rewrite the LDAP Provider (maybe the OpenLDAP folks?) and install it ... > Is it possible that MSFT will throw in some flaw that only > manifests itself when you use none AD directories? This is always possible ... and I would suggest that it would probably be discovered fairly quickly ... and should be reported to the press if it happened. AND this could then be an area of extensive discussion about legal issues ... ;-) > Could they optimize their ADSI only for their AD and exclude the > possiblility of optimization for other directories? Hmmm ... I would have to dig deeper into the actual architecture of the ADSI layer ... this is related to your previous question. If the API more closely matches their directory architecture, then they might gain some advantage ... > How much of this should be permitted from a monopoly? I do agree that if any evidence could be found that they are building in flaws to purposely cripple competitors products, then the issue needs to be examined closely. But when I did presentations about this subject with customers, I went back to my arguement that the customer needs to be aware that even if they are not going to choose non-Microsoft products ... they should be concerned when their vendor starts to make product decisions for them. > It seems to me that Microsoft has a path for directory applications > developers that first excludes all non-Windows platforms for > development. Well ... I'm not sure about this. They are not a "cross-platform API developer" ... they are writing Windows. So they have had a focus on doing development of Windows. I guess that what I'm thinking is that all vendors write for their platforms ... first. > Second is the question of how open they have been with Novell with > those ADSI API's? Open enough that Novell could write an ADSI provider for NDS ... and they've had it available for a long time on the Novell web site ... > Am I asking the right questions yet? Yes! Very much so ... Scott C. Lemon