RE: [hyades-dev] The state of the HCE project

[Harm Sluiman <sluiman@xxxxxxxxxx>]

I will not pretend that I have been
deep in this thread of discussion, and Richard Duggan is the lead for this
area. Richard is out on some vacation for a while so I feel I should comment.

First, a guiding principal is that we
make changes to the existing and so far well working system based on well
identified requirements, and we make those changes in the spirit of no
breaking apis, a minimum of 3 years of support once provided, and on the
development cycles defined for Hyades. There are a set of these requirements,
although as yet poorly documented other than a single line in the plan
on the web site. 

Second is a somewhat obvious commitment
that we actually leverage and exploit these capabilities in our own Hyades
tools.

I have assumed that all these design
discussions are within these contexts, and the upcoming face to face meeting
is intended to close on the current discussions and close on some of the
implementations.

That said, the current system certainly
can not go away and in fact has to continue, and this has to be more than
code reuse. It has to preserve the current support and grow to meet the
new needs.

Mike has added another good point in
that it make s perfect sense to be able to use some of the components in
Hyades in other execution environments and we don't want to discourage
that, but not at the cost of depreciating our own infrastructure. If there
are specific issues we have, then we need to address them, and I leave
that to the subsystem workgroups to resolve.

Thanks for your time.
--------------------------------------------------------------------------
Harm Sluiman, STSM,  
phone:905-413-4032   fax: 4920  
cell: 416-432-9754
mailto:sluiman@xxxxxxxxxx
Admin : Gabrielle Chapman chapmaga@xxxxxxxxxx  Tie: 969-2323

"Nguyen, Hoang M" <hoang.m.nguyen@xxxxxxxxx>
Sent by: hyades-dev-admin@xxxxxxxxxxx

08/31/2004 10:39 PM

Please respond to
hyades-dev

To	<hyades-dev@xxxxxxxxxxx>
cc
Subject	RE: [hyades-dev] The state of the HCE project

Allan,
 
Here are my opinions:
 
·
        First,
we don't really get rid of the current system.
The new system will adopt and reuse
many working features and code
such as: shared memory operations,
inter-process communication,
process startup, socket management,
thread management, configuration,
build system, etc.
 
·
        We are
re-structuring the existing systems with components
and introducing better and cleaner
interface between these.
We re-define and formalize a lot of
custom commands to become
standard interfaces.
 
·
        Regarding
the usage of XML vs. binary structure, it is much like C, C++, Java, C#
or even Visual Basic. Each has its own advantage and its own place in the
application implementation.
 
We tried to put in place the infrastructure
that supports both XML and binary structure. It depends on the purpose
of the application, the user has the option to use either.
 
Intel software tools such as VTune
requires performance and place strong emphasis on that criteria. Others
may not.
 
We make sure our new system supports
SOAP messages. That is another option that other products may want to make
use.
We want to create and foster a common
multi-purpose infrastructure.
 
·
        There
are specs and various implementation of system out there.
But can you really recommend a system
to start from?
Personally, I don’t think there is
one. Each system has certain pros and cons. Each system will require similar
or even much more amount of work to customize and make it flexible. Each
may be specialized for a single purpose.
 
VTune product has its own remote communication
component providing similar capability to HCE. But we have evaluated and
decided that
it is better to adopt and create a
common infrastructure for all products (across different companies as well)
instead of spending the effort to maintain
our own propriety component
for our product usage only.
 
It is the intention this new open source
HCE infrastructure will provide the needed plumbing work that no other
product will ever need to re-invent the wheel.
By using the same plumbing, all products
can interoperate better.
 
 
In short, we do want to leverage existing
implementation and 
adopt the best standards possible.
That is why we continuously
solicit inputs and encourage more participation.
 
We start out initially with the current
HCE,
define a flexible plug-in architecture,
and add on new components with the
best selected technologies 
that we are aware of.
 
This is where we need to work together
as a community
to validate and contribute to this
effort of building this common infrastructure.
 
Right now, we think the current HCE
is the best system to start from
unless anyone can point out a better
system that
can really help shorten our development
effort to achieve our goals.
 
Just my own humble opinion. 
Like Allan, I welcome more inputs and
comments to this topic.
 
Regards,