Programando em NCL 3.0.pdf - Telemidia - PUC-Rio
Programando em NCL 3.0.pdf - Telemidia - PUC-Rio Programando em NCL 3.0.pdf - Telemidia - PUC-Rio
pode ser sintonizado em qualquer instante de tempo de um programa de TV.O escalonador deve também permitir que uma aplicação sofra operações depausa e retomada, que exigem que ela prossiga, mesmo em um instantetemporal posterior ao da pausa. Esse tipo de operação é comum quando ousuário troca e, em seguida, retorna ao mesmo canal (ou serviço) de TV.Para enfrentar o segundo problema, o gerenciamento das transmissões,devemos definir procedimentos, tanto nos provedores de conteúdo quanto nosclientes receptores. Esses procedimentos dependem de os dados seremrecebidos sem solicitação (pushed data) ou sob demanda (pulled data).No caso de dados recebidos sem solicitação, eles são geralmenteenviados ciclicamente (em carrossel), como discutido em detalhes noApêndice F. A colocação e a retirada dos dados no carrossel e em qualposição do carrossel são fundamentais para diminuir a banda necessária paratransmissão dos dados e para garantir que eles estarão presentes no receptorquando necessário. O “escalonador de carrossel” é o responsável por essastarefas nos provedores de conteúdo.Do lado do cliente receptor, um “escalonador de pré-busca” é necessáriopara retirar, nos momentos precisos, dados dos carrosséis e carregá-los namemória do receptor. Esse escalonador é também responsável por requisitardados sob demanda, de forma a garantir sua presença no dispositivo receptorquando necessário. Devemos notar, mais uma vez, que devido à usuallimitação de memória dos dispositivos receptores é importante manter omínimo de conteúdos de mídia na memória principal. Para busca dessesdados, pode ser necessária a negociação de QoS (Quality of Service) na rede.Nesse caso, um “escalonador de negociação de QoS” é responsável pelatarefa, garantindo a reserva de recursos na rede quando o escalonador de prébuscarequisitar os dados.Para dar suporte à realização das tarefas executadas pelos diversosescalonadores mencionados, várias estruturas de dados são computadas apartir da especificação da aplicação NCL. Na implementação de referência domiddleware Ginga, elas são baseadas e derivadas de uma estrutura de dadosúnica, denominada Hypermedia Temporal Graph ou HTG.G.2 Hypermedia Temporal Graph (HTG)Para controlar o comportamento temporal das aplicações durante a suaexecução, o Ginga-NCL adota uma estrutura formada por grafosdirecionados (dígrafos). Essa estrutura, conhecida como HypermediaTemporal Graph ou HTG[Costa et al., 2008; Moreno et al., 2008], oferecesuporte ao início ou à retomada síncrona da apresentação a partir de uminstante de tempo qualquer.520
No HTG, cada vértice representa uma transição de estado de um evento.Os eventos representados nessa estrutura são os mesmos definidos na NCL,ou seja, os eventos de apresentação, seleção e atribuição, cada um controladopor uma máquina de estados, repetida por comodidade de leitura na FiguraG.1.stop | abortpausedpausesleepingstartstop | natural endabortresumeoccurringFigura G.1 Máquina de estado de um evento.O grafo temporal obtido através da modelagem de uma aplicação devepreservar todos os relacionamentos entre os eventos, sejam eles previsíveis ouimprevisíveis, bem como o estado atual de cada máquina de estados associadaa um evento.No HTG, as arestas entre os vértices representam os “relacionamentosentre as transições de estados dos eventos”. Cada aresta possui uma condiçãoassociada que deve ser satisfeita para que a transição, representada pelo seuvértice de destino, seja disparada. Em resumo, os grafos nessa estrutura sãodefinidos por um conjunto de vértices, arestas e condições de caminhamento(V, A, C), onde: V = (v0, v1, v2, v3, ..., vn – 1) é um conjunto finito de vértices, em quecada vértice representa uma transição na máquina de estados associada aum evento. Cada vértice é representado por uma tripla: o nome da açãoque dispara a transição, o tipo de evento correspondente e o identificadorda âncora que identifica o objeto ou parte de seu conteúdo (se o evento édo tipo apresentação ou seleção) ou o identificador único da propriedade eseu valor (se for um evento de atribuição); A = (a0, a1, a2, a3, ..., am – 1) é um conjunto finito de arestas querepresentam, individualmente, um relacionamento entre transições. Paracada aresta “a”, v e w são os vértices de origem e destino, respectivamente((v, w) V x V); C = {cij} é um conjunto finito de condições associadas às arestas. Umacondição “cij” é associada com a aresta (vi, vj) A e deve ser satisfeitapara que o disparo do vértice (disparo da transição) destino da arestaconsiderada seja realizado.521
- Page 509 and 510: Note que a definição de dois tipo
- Page 511 and 512: 2..nidRule1..* ruleList1..*0..10..*
- Page 513 and 514: podem ser estendidas: evento de exi
- Page 515 and 516: Um evento de apresentação pode mu
- Page 517 and 518: C.9.1 ConectoresA Figura C.6 ilustr
- Page 519 and 520: RoleideventTypeminCardinalitymaxCar
- Page 521 and 522: condição ou avaliação, quanto u
- Page 523 and 524: opcionalmente negada. Qualquer expr
- Page 525 and 526: de estados de eventos, a ideia é f
- Page 527 and 528: Por outro lado, a exibição do nó
- Page 529 and 530: C.10 Objetos de Dados XObjetos de R
- Page 531 and 532: O NCM define uma classe descritor g
- Page 533 and 534: navegação em um documento. Usuár
- Page 535 and 536: i) ela pode conter nós de conteúd
- Page 537 and 538: D.1 Conectores CausaisNo Capítulo
- Page 539 and 540: Listagem D.1 Exemplo de base de con
- Page 541 and 542: E.1 IntroduçãoUm receptor pode co
- Page 543 and 544: Como mencionamos, um NPT pode come
- Page 545 and 546: F.1 IntroduçãoComo mencionamos no
- Page 547 and 548: Assim, quando um comando de ediçã
- Page 549 and 550: carrossel de objetos diferente daqu
- Page 552 and 553: documento XML representando o metad
- Page 554 and 555: Sistema de Arquivo LocalC:\nclRepos
- Page 556 and 557: Tabela F.4 Indicação de Fragmento
- Page 558 and 559: Apêndice GHTGA apresentação com
- Page 562 and 563: As condições podem ser simples ou
- Page 564 and 565: condição de percurso de uma arest
- Page 566 and 567: propaganda é inserida no meio de u
- Page 568 and 569: passa a construir o grafo temporal
- Page 570 and 571: Apêndice HComportamento deExibidor
- Page 572 and 573: A instrução start emitida por um
- Page 574 and 575: associado ao elemento, mesmo se out
- Page 576 and 577: H.2.1.3 Instrução abortNo caso de
- Page 578 and 579: deve ser realizado por instruções
- Page 580 and 581: Para objetos de mídia com código
- Page 582 and 583: No caso de objetos de mídia com c
- Page 584 and 585: Se a composição contiver elos sen
- Page 586 and 587: ncl-NCL”, todas as portas do docu
- Page 588 and 589: Se o objeto de mídia com código d
pode ser sintonizado <strong>em</strong> qualquer instante de t<strong>em</strong>po de um programa de TV.O escalonador deve também permitir que uma aplicação sofra operações depausa e retomada, que exig<strong>em</strong> que ela prossiga, mesmo <strong>em</strong> um instantet<strong>em</strong>poral posterior ao da pausa. Esse tipo de operação é comum quando ousuário troca e, <strong>em</strong> seguida, retorna ao mesmo canal (ou serviço) de TV.Para enfrentar o segundo probl<strong>em</strong>a, o gerenciamento das transmissões,dev<strong>em</strong>os definir procedimentos, tanto nos provedores de conteúdo quanto nosclientes receptores. Esses procedimentos depend<strong>em</strong> de os dados ser<strong>em</strong>recebidos s<strong>em</strong> solicitação (pushed data) ou sob d<strong>em</strong>anda (pulled data).No caso de dados recebidos s<strong>em</strong> solicitação, eles são geralmenteenviados ciclicamente (<strong>em</strong> carrossel), como discutido <strong>em</strong> detalhes noApêndice F. A colocação e a retirada dos dados no carrossel e <strong>em</strong> qualposição do carrossel são fundamentais para diminuir a banda necessária paratransmissão dos dados e para garantir que eles estarão presentes no receptorquando necessário. O “escalonador de carrossel” é o responsável por essastarefas nos provedores de conteúdo.Do lado do cliente receptor, um “escalonador de pré-busca” é necessáriopara retirar, nos momentos precisos, dados dos carrosséis e carregá-los nam<strong>em</strong>ória do receptor. Esse escalonador é também responsável por requisitardados sob d<strong>em</strong>anda, de forma a garantir sua presença no dispositivo receptorquando necessário. Dev<strong>em</strong>os notar, mais uma vez, que devido à usuallimitação de m<strong>em</strong>ória dos dispositivos receptores é importante manter omínimo de conteúdos de mídia na m<strong>em</strong>ória principal. Para busca dessesdados, pode ser necessária a negociação de QoS (Quality of Service) na rede.Nesse caso, um “escalonador de negociação de QoS” é responsável pelatarefa, garantindo a reserva de recursos na rede quando o escalonador de prébuscarequisitar os dados.Para dar suporte à realização das tarefas executadas pelos diversosescalonadores mencionados, várias estruturas de dados são computadas apartir da especificação da aplicação <strong>NCL</strong>. Na impl<strong>em</strong>entação de referência domiddleware Ginga, elas são baseadas e derivadas de uma estrutura de dadosúnica, denominada Hypermedia T<strong>em</strong>poral Graph ou HTG.G.2 Hypermedia T<strong>em</strong>poral Graph (HTG)Para controlar o comportamento t<strong>em</strong>poral das aplicações durante a suaexecução, o Ginga-<strong>NCL</strong> adota uma estrutura formada por grafosdirecionados (dígrafos). Essa estrutura, conhecida como HypermediaT<strong>em</strong>poral Graph ou HTG[Costa et al., 2008; Moreno et al., 2008], oferecesuporte ao início ou à retomada síncrona da apresentação a partir de uminstante de t<strong>em</strong>po qualquer.520