Redirecting discussion from the internal vt list to the proper forum for 
discussion of OSSIE development.

-------- Original Message --------
Subject: Re: Component Updates for 0.6.2
Date: Tue, 5 Feb 2008 12:06:05 -0500
From: Philip Balister <[log in to unmask]>

Here is a half-baked idea:

interface foo {
	void pushPacket(someData);
};

interface foo-meta : foo {
	void update-meta(someMetaData);
};

Now the uses part of of the connection uses _narrow to work out if the
provides supports meta data. The component side of standard interfaces
always accepts calls to update the meta data, but only sends it when the
uses port supports it.

Voila! Now we can mix components that support meta-data with components
that do not.

Now back to paying work.

Philip

Joseph Gaeddert wrote:
> Philip brings up a good point: we should probably sit down and discuss what
> interfaces we should consider comparing.  Currently the complexShort interface
> has two methods: pushPacket and pushPacketMetaData.  Because IDL does NOT allow
> two methods with the same name (this is because not all languages support this)
> they must be implemented separately.  However, the port implementation in C++
> implements pushPacket(ShortSequence) and pushPacket(ShortSequence, MetaData)
> and is (I'm 90% sure) binary compatable with the non-metadata standard
> interfaces.
> 
> See http://ossie.wireless.vt.edu/trac/wiki/MetaData
> 
> I'm not saying it's the best solution, because it probably introduces more
> overhead than necessary, but it is a solution.
> 
> I can sketch out a testable interface in IDL for comparison of raw data, data w/
> IDL-defined metadata, and data w/ XML-based descriptors.  We should then run
> some benchmarks to compare
>   1. efficiency between two components running on same machine
>   2. efficiency between two components running on different machines
> 
> -jd
> 
> 
> Quoting Philip Balister <[log in to unmask]>:
> 
>> Joseph Gaeddert wrote:
>>> Haris,
>>> Yes, many people have this concern, but I don't think anyone has really
>>> profiled the overhead to see how much it really affects it.
>>>
>>> Drew,
>>> Yes, I would be interested in getting some profiling results done this
>>> week.  How about tomorrow or Wednesday morning?
>> Some quick notes:
>>
>> 1) Until there are a couple of mets-data implementations to compare,
>> profiling is a little premature. Profiling the meta-data versus no
>> meta-data case is not particularly interesting, since we pretty much
>> know we need to have a meta-data feature of some form.
>>
>> 2) So, what are the possible solutions:
>>
>>   a) Current implementation (I've only looked at the idl) based on
>> sending discrete predetermined data.
>>   b) A free form xml based solution.
>>   c) Change ports to use two separate interfaces, one for data, one for
>> meta-data and have standard interfaces deal with the case where you
>> connect a meta data to a non-meta-data port.
>>
>> It should be possible to prototype several cases and create a simple
>> waveform to use the interfaces, then you can profile the different
>> implementations and make some real decisions.
>>
>> The reason for trying xml is to avoid marshalling the discrete types and
>> see if the xml parsing is better than the marshalling. By separating the
>> interfaces, you should be able to update the metadata only on change.
>>
>> In other words, I still see a fair bit of work that needs to happen
>> before a final decision is made. This work should not delay work on the
>> 0.6.2 component library. I have already heard from people who were very
>> surprised the 0.6.2 vmware image did not come with any useful components.
>>
>> Also, this work should not be left up to Joe, more people need to get
>> involved in actually writing code for OSSIE. The only way to learn, is
>> to sit down and actually do something (besides attend meetings and write
>> emails).
>>
>> Philip
>>
>>
>