[hyades-dev] blobs and such matters

[Harm Sluiman <sluiman@xxxxxxxxxx>]

It is hard to follow all the threads
and thoughts in these notes. Too many smart people with good ideas ;-)

Regarding BLOBS. This is always a concern
that I worry about as well. There are two reasons this is a concern regardless
of where in the model they are.
1. It is a specialized contract between
the producer and consumer that is apparently not good enough to publish
for everyone's use as first class data in the model. 
2. Everything we put in the model will
exist and have to be supported in future variants of the model for several
years to come. By it's very nature a BLOB is fragile because no one knows
it's crisp content or structure at a point in time and it is in effect
proprietary.

Hyades models are for open integration
so BLOBS are in conflict. However the reality is that Hyades needs to allow
it's users to extend with proprietary "value add" data and function,
so the model needs to allow these things. This is also typically a way
to handle things that are needed but can't be completely resolved publicly
in time for a given release. So to answer Mike's question about waiting,
I don't think we can avoid this. 

We actually have two tasks to resolve.
1. How to do this properly
2. Should we even exploit this in Hyades
itself.

It seems it has already been concluded
that leveraging the basic name/value pair paradigm is the way to go, and
augmenting it with a type property to make it interpretable seems right.
We end up with a typed/name/value pair. We do need to articulate very well
what the understood values for the type and name are. An enumeration in
the model is not extensible enough, but I understand a plugin extension
point to register values is being looked at and this seems right as long
as it is well documented.

As for the "should we use this'
question, it appears obvious we have a need to support some incomplete
capabilities, at least from the sense of public closure in time for 3.0.
This should fall into the "internal" category of function we
provide so no one become dependant on the support and we are the only ones
dependant on it.

Back to this specific case. the name
UI provider is a really bad name. In a MVC view of this UI is a View layer
and this is a value at the Model layer so we need a "type" value
that describes it content and not a speculation of it's use.

This is not a basic facade problem.
Although always debated, the facade has the role of simplifying the model
concepts via a set of helper classes for manipulating the model. The facade
is where we need the internal classifications because these are temporary
concepts, unless we are very confident at the facade layers and are only
struggling with persistent state form of the data.

Bottom line is that it appears the current
effort is appropriate given where we are, but we need to do this internal
demarkation, and we need to resolve any blob usage in Hyades as quickly
as possible post 3.0.0.

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

Michael.Norman@xxxxxxxxxxxxx
Sent by: hyades-dev-admin@xxxxxxxxxxx

03/22/2004 07:20 AM

Please respond to
hyades-dev

To	hyades-dev@xxxxxxxxxxx
cc
Subject	RE: [hyades-dev] Hyades Execution results

This stuff about Hyades endorsing the use of proprietary
BLOBs in the 
data model, makes me extremely nervous. Do we really need to solve this
now? At this stage fo the game the execution history is being 
overloaded. Can't we wait until the trace models are richer and more 
coordinated and we can trace all the elements in the behaviour 
(Datapools, SUTs, Arbiters, internal behaviorual elements such as loops)
in a coordinated linked fashion?  

If we need to solve this problem now, at this stage I think the 
requirement relates primarily to external behaviours, or to things 
driven off the facade.  If this is the case then my intuition is to
use 
the facade (it's kind-of what it's for) and for external behaviours the
test type (it's our gating mechanism across the external behaviour "cat
flap" in the current model), rather than building a whole bunch of
additional proprietary rat-holes in the data models.

If we do go ahead with this BLOB stuff, we're doing something very 
similar to MIME, and the right thing to do is (as MIME does) to specify
the nature of the BLOB not the way it is to be processed.  With MIME
it's up to the browser to invoke the right plug-in.  The point about
the 
proposed UI provider hook is it is not generic. It's not even fit for 
our future purposes in Eclipse.  We are pre-judging the processing
we 
will have to apply to these BLOBS. Who knows the things we may have to
do with them in the future.  I certainly envisage invoking a virus
checker on them :-) 



Mike



-----Original Message-----
From: gian.franco.bonini [mailto:gian.franco.bonini@xxxxxxx]
Sent: Friday, March 19, 2004 1:40 PM
To: hyades-dev
Subject: [hyades-dev] Hyades Execution results


Hi,
 
Some follow-up to yesterday's test model meeting.
 
I can see different use cases for a UI provider associated to the 
execution events: 
1. differentiate between e.g. the various start events (start loop, 
start test execution, etc)
2. allow flexible text display for internationalization purposes
3. allow test-tool-specific icons and texts (e.g. invocation of a JUnit
test shown in a different format from an HTTP test)
4. allow icons and texts to depend e.g. on the behavior element 
associated with the execution event.
 
Is that roughly accurate? Am I missing any important use case? 
Apart from some quibbling on minor points, I agree that for 1-4 
something like the suggested extension point is needed 
I still have a couple of remarks:
* It would be nice to solve Problem 1. in the standard viewer, however
e.g. loop is a façade concept and therefore not fully generic. Could we
implement - as part of the façade - a UI provider to display the 
different start events according to the element that has been started?
(Execution Event has a reference to an Interaction Fragment which could
be used to identify the correct façade element). That would already 
improve the appearance of the typical execution result (of course tests
that use the façade  could still override the default UI provider
for 
more specific texts/icons) 
* Are there any plans to support I18n of execution results in a generic
way? We're probably not the only ones to think of it as a valuable 
addition 
* To solve 3. and 4., the UI provider could be also triggered not by an
attribute in the execution event but by the test suite type. In fact, 
unless there is interoperability between vendors, one way or the other
won't make any difference. 
 
One use case that is relevant to us is that we might want to use UI 
providers from third-party tools in environments other than Eclipse 
(e.g. in a browser). That would be feasible as long as the provider 
interface does not explicitly refer to Eclipse-specific (SWT-based) UI
elements. What's the signature of the UI provider methods? getLabel can
return a string, that would be fine. It would be nice if getIcon could
also return some SWT-independent object.  
 
Concerning the other topic under discussion (adding to each execution 
event a collection of triplets name-type-value):
We definitely have use cases for that. The points that Martin mentioned
in a previous post could be for example accommodated as follows:
* Reference to the SUT: we might add a triplet name="SUT", type=<the
specific SUT Type>, value=<some (XML-)String identifying the SUT
element 
relevant to the execution event> 
* Reference to datapool entries used as input: add a triplet 
name="IN_DATA/variable name", type = "Datapool", value=<some
representation of a datapool cell or record, or a reference to it> 
* Non-datapool variables after a given event: add a triplet 
name="OUT_DATA/variable name", type = "variable type"
value = "<some 
representation of the value>" 
We'll have to adopt namespaces and hierarchical names to overcome the 
lack of deep structures, but as a first step I guess it will do. Once 
e.g. the SUT is modelled (or if other stakeholders agree that a 
reference to the SUT is a meaningful thing to have), the SUT-triplet 
could be promoted to model attribute in its own terms, maybe in a more
suitable form.
 
Gian Franco
 
-------
Gian Franco Bonini
SAP AG
 

_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev

_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev