I realize that this response is very late, but this seems to be a
common misunderstanding, so I hope I'll be forgiven for the tardiness
of my reply:
> For Oracle's i initiative, there does have to be a > Java "interpreter," on the client.
> Albeit, it's small. But the bigger drawback is the size of the
> Java app being sent
> down to the client. I'm guessing the more complex the app, the
> larger in size it is.
This would be a serious drawback if it were true, but it isn't.
The "i initiative" that Oracle is pushing is to encourage people
to write server applications in Java. That is, the application logic
runs in the server and is written in Java. At its simplest, the client
is a standard web browser. The idea is that instead of writing the
application to run in some homemade server using Apache and perl and
OCI and an RDBMS all together, you just write the application to run
in the database and have the database be the webserver. (In the
next release of 8i there will be a webserver in the database -- there
is already a demostration version of a webserver in the first
release.)
Obviously there is a lot more to this than just "stick an application
in the RDBMS", since you have to have tools, distributed databases,
replication, security, legacy code, ... But the basic model is very
simple. |
