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 : LINUX -- Ignore unavailable to you. Want to Upgrade?

To: JC Jaros who wrote (1695)	8/8/1999 12:35:00 PM
From: E. Charters	Respond to of 2617

We may have Special Excludable X objects in order to preserve legacy compatibility with X-Windows. If we broker them commonly we may be accused of running a Common S.E.X. Object Request (solicitation) Brokerage House and there could be penalties for that. GUI would pass X requests or calls transparently so X programs would run as clients under this Client server system. There may be no reason not to CORBA the architecture if object oriented programming is used. I am a bit leery of CORBA as 4GL programs get so big and then object confusion sets in. Really large programs are better off using standard non-event driven programming techniques. 80% of 4GL language projects fail because of code complexity and bloat. Most of the rescues are written in standard procedural languages that are known to work, like COBOL. If we write databases in XML then there is no need to write them with CORBA standards as XML may eventually form a standard to access many types of databases. But I will admit that where it is likely that procedures, aka objects will be used by other CORBA implementing programs then it may pay to do things according to that architecture. It is a point to ponder. I would like to be assured that the speed, development time and usability of the project would be improved before leaping to any "standard". I would like to see that other large projects of this kind have benefited from such adherence. Don't forget that we may inherit much of the code from an already written code base. This is the advantage hopefully of tackling this project. If we wanted the thing to run fast we would write it in FORTRAN which is faster than C and does graphics well. (OK really good flexible powerful graphics might need another language) It is slightly weak on data structures but is a much better compiler when it comes to nesting and overall structure. C is a functional nightmare with no structure at all. C++ is an even more nightmareish usage of C, with every greater pitfalls and traps lurking under its hidden semi-re-usable code. No less than Ritchie has said that C++ is an abomination and obsolete. If he said it I rest my case. RESERVAC the immense Air Canada dynamic database and reservation system was written in Fortran because they wanted the thing to work, be fast and they had to get hundreds of programmer to write in the language quickly. It is the still the best and fastest program of its kind. I would not want to write such a beast in OOP. You would never get done and if you did it would crash once a day at least. EC<:-}

To: JC Jaros who wrote (1695)	8/8/1999 1:23:00 PM
From: E. Charters	Read Replies (1) \| Respond to of 2617

Java has a connection with this Client Server system I envision. But Java which was developed to run a virtual machine interpretively is S.L.O.W. (sucks lots of wind). It may never be the machine of choice to run anything. It functions on the net to jazz up the browser but it is stop gap really. XML and other architectures have more promise. I would not run a computer on Java.. Why? Its primary purpose is downpipeline interpreted or JIT compile code. Common code is much safer and more controllable. The basic security hole in Java will never be plugged. You never know where the code is coming from and what it will do. (Godl proved that no code detector that did not alter the OS could detect code that altered the OS.) Today despite the widening implementations of Java I cannot see it living up to any kind of promise. It would have been possible to revamp HTML to do much the same thing. This IS a direction we should go down. XML should be pushed to the highest level post haste. This is a really exciting intercommunication tool. It is these kind of doable solutions that make the more complex things like CORBA eventually obsolete. Not that CORBA is a bad idea, but I don't know if its the winner yet. Extensible servers work fine on an intranet where trusted code is the order of the day. Trusted code would come from major programs that would operate that way. In this way trusted servers who commonly interact with clients could pass code fragments that would act CORBA like on virtual machines and obviate the necessity of large code bases existing everywhere. This is not a mass herd solution though. It is a business/institutional need more than anything else. But then again the existence of ubiquitous display and rendering packages whose routines could be called with CORBA type calls (down pipe code extensibility) OR common display/browser packages, i.e. netscape-like with complex manipulation routines may make one the other obsolete. Who will win? We cannot keep up the war forever. I will bet the cheapest one wins. Cheap means development time as much as cost to implement. So the code base or program may eventually end up being common. The common interface is tempting. Which is higher bandwidth? Would the net operate with common code interface alone as Java tries to implement? I think not. So why bastardize it? I think extensibility and client server will walk hand in hand with widely available code for many moons. The reason being is that not everybody will have all programs. But browser-like solutions are tempting. I just can't see people giving them away forever. Java is neat. It could be implemented in other ways more safely but not more flexibly. I see low level Java as being around for quite a while and high level compiled extensible solutions developing too. Trusted Intranet software is actually a nascent and untapped area that people like Oracle will be delving into in the future. The actual architecture of the system I envisioned is extensible. I did not intend that it operate across the internet that way as it would require too high a security component in the code. But it would lend itself to intranet extensible graphical solutions. This would be a solution where flexibility was required and code bases were very large and diskless terminals where common. Java could be implemented on this architecture quite easily for internet usage. That is a no brainer as Linux has Java support. XML would be its big Kahuna as the OS could respond directly to XML commands and files built in "term" windows could be stored as XML files, either database or formatted text. Databases could be for jottings related to OS or user activities, incoming or created files, mail, and other communications. It could all be stored in XML format. Files for uploading could be stored in XML or HTML or whatever and accessed according to the capabilities of the remote browsers by some protocol. The idea is to use XML as a native language of the OS so that a browser would not be necessary. Files accessed across the net would just display in a window on the system. This is the direction that MS headed in by trying to expropriate everything to VB, active X and IE and making the OS more browser like which as we have seen is an advantage. Let's hope XML succeeds as a standard instead. Remember what Hegel said.. every idea contains inherently its own contradiction. EC<:-}