[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Back to the basics
From:       Graham TerMarsch <gtermars () home ! com>
Date:       1999-09-29 19:17:05
[Download RAW message or body]

Daniel Naber wrote:
> Frankly, I'm surprised nobody seems to see the power of
> remote components and how important they migt get. Today,
> you surf the net to look at html pages. Tomorrow you'll surf the
> net to try out a new spreadsheet - without installing it! Just
> embed it into your documents. If you like it, you can still
> download it.
[.....snip.....]
> KDE has achieved so much - today we cannot just think
> "but I never saw that in real use upto now" but be have to look
> into the future. And not just that, if there's a vision like "remote
> components everywhere" we can *make* it come true, we
> don't have to wait for others to do so!

From being another person "on the outside" of this discussion looking in, I
think that valid points have been made on all sides of the discussion here. 
As well, I've worked with organizations who are doing heavy CORBA stuff in
order to integrate disparate systems across the network and create a complete
distributed networked application.  Works great, but does have performance
issues (which I'm not sure will ever go away, just due to the variety of other
constraints that need to be addressed).

Personally, I think that going with the approach of having _both_ kinds of
embedding be possible is the best solution (by that's my opinion, so take it
with a block of salt).  As a developer, I'd rather have a shorter learning
curve and more reliable code/libraries to work with, and live with not having
full network transparency in my app in the short term.  In the long run, I can
definately see and vote for the advantages that having a fully CORBA system
provides, but at this stage I'd question as to whether that's pushing the
envelope a bit far.  If I were to really throw a ball of wax into this, I'd
think that having the "quick and fast" implementation would be useful in the
short-term, provided that there's a roadmap outlined as to how we get from
there to a full CORBA based system.

As for compatibility with other CORBA systems and their interfaces, I'd have
to say that its something to be looked at, discussed with their developers,
and worked on, but at the same time unless they're also willing to come to the
table to strive for the same goals then I'm not sure whether it'd really be
worth the additional effort for us to march along building it without their
cooperation.  Note, though, that I can't say to what degree other parties are
or are not willing to come to the table, but am going to presume that out of
the variety of different suites/applications/teams out there that we'll likely
find some that are willing to cooperate while also running into others that
are not.

Short version: I'd like to have something useful that I can start to use now,
knowing that in the next incarnation its going to be more robust and allow me
the network transparency that I'd really like to have.

-- 
Graham TerMarsch

// -----------------------------------------------------------------
// fortune: cpu time/usefulness ratio too high -- core dumped.   
// -----------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]