OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [emergency] MPEG (was Re: [emergency] usage scenarios)

On Thu, 2005-08-18 at 22:45 -0700, Art Botterell wrote:
> On Aug 18, 2005, at 8/18/05 9:16 PM, Kon Wilms wrote:
> > If data can be referenced or delivered by other means then it
> > should not be encoded into the payload.
> OK, that's pretty clear... I'll describe it just that way in the  
> updated Issues List, forthcoming shortly.

Sounds good. See, we do agree sometimes. ;-)

> Personally, I'm still not sure a content standard is the right place  
> to try to enforce that sort of policy.  I think a case could be made  
> for allowing DEs to be atomic for data-integrity and synchronization  
> reasons, especially in mixed two-way/one-way network environments.   
> And I think we should allow the implementers to make their own  
> capacity/performance judgments.

I can see a use in one-way networks where the payload is embedded
because a delivery mechanism is not advanced enough to manage queuing
and delivery of content before metadata (being the EDXL message). But I
can also see a use where the delivery system can support queuing and
deal with content that does not arrive in the desired order at the
receiver. My personal preference is to use one mechanism to deliver the
EDXL data and the referenced file data, QoS the EDXL messages over the
other data, and provide URIs which point to the local cache where the
remote assets will be delivered to. This follows the age-old tried and
tested electronic program guide delivery paradigm, where assets are
carouseled continuously out-of-band to the guide data transmission. But
that's just one example, and to each his own.

> But I certainly wouldn't have any problem with Rex's offer to  
> substitute something less massive-sounding for the purpose of our  
> example.

Sounds perfect to me (and a good example to boot). It would be nice to
see people optimizing the payload (in this particular MPEG example) by
snapshotting a preview of the actual content to a Jpeg. Many asset
management systems work this way, and it helps with visual
categorization of data. Often it is quicker to visually assess data than
it is to read the alert information.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]