perl-oak-discuss-br Mailing List for Perl Oak
Brought to you by:
ruoso
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(23) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|
From: Daniel R. <da...@ru...> - 2006-07-10 21:26:03
|
Ol=E1, Vamos l=E1... pensando mais um cen=E1rio de uso, desta vez com PDA. Como falei no outro email, o que vai identificar o PDA =E9 a intermit=EAncia n= o acesso =E0 rede e restri=E7=F5es extremas de hardware. Para ajudar a pensar, pensamos um cen=E1rio simples de um vendedor utilizando um PDA para lan=E7ar pedidos. Algumas caracter=EDsticas t=E9cnicas devem ser respeitadas: 1) O sistema deve ser atualizado automaticamente. 2) M=F3dulos devem ser disponibilizados de acordo com as credenciais de autentica=E7=E3o do usu=E1rio. 3) O sistema n=E3o pode depender de conex=E3o =E0 rede para operar. 4) A plataforma n=E3o pode depender de daemons ativos, uma vez que o sistema operacional do PDA pode ser mono-tarefa. A proposta que conseguimos elaborar (izut++) =E9 a que est=E1 no diagrama= em anexo. daniel |
From: Daniel R. <da...@ru...> - 2006-07-07 20:11:16
|
Em Qui, 2006-07-06 =E0s 17:22 -0300, Daniel Ruoso escreveu: > "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos > atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1rio= em um ou > mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente?= " Depois de algum debate (izut++), conseguimos chegar a uma proposta para essa interface. A solu=E7=E3o teve como inspira=E7=E3o basicamente a id=E9ia de screen-wi= de menus do mezzo (symphonyos), e da proposta de portais em si (tomando como exemplo a p=E1gina inicial do google), al=E9m da interface do iPod. No entanto, simplesmente exibir portlets n=E3o =E9 suficiente para ser considerado como ambiente de trabalho, primeiro por que existe a limita=E7=E3o de um n=FAmero de portlets que =E9 razo=E1vel exibir em uma= p=E1gina, e segundo por que ter portlets que o usu=E1rio raramente usa seria um desperd=EDcio e um preju=EDzo =E0 usabilidade. Neste ponto encontramos dois desafios: 1) Como lidar com a quest=E3o de exibir um n=FAmero maior de portlets sem precisar ter muitos portlets ao mesmo tempo? 2) Como lidar com portlets que s=F3 s=E3o utilizados esporadicamente e qu= e n=E3o mere=E7am estar em exibi=E7=E3o? Para o primeiro desafio, novamente inspirado pelo mezzo vimos que seria poss=EDvel um usu=E1rio ter v=E1rios portais (que, coloquialmente chamamo= s de "mesa"), onde ele poderia distribuir portlets =E0 sua maneira. Um portlet especial, provido pela plataforma permitiria a navega=E7=E3o entre esses portais, o portlet "Meus Portais". Para o segundo desafio, pensando na interface do iPod, pensamos que seria poss=EDvel criar menus n=E3o hierarquizados que voc=EA acessa progressivamente. Ent=E3o existiriam portlets de menu, que exibiriam outros portlets sem que esses portlets tivessem que ser necessariamente adicionados a nenhuma mesa. Mas que depois de visualizados, o usu=E1rio poderia adicionar aquele portlet a uma mesa existente ou criar uma nova mesa/portal para alocar aquele portlet dentro. E por fim, para resolver a quest=E3o de que os m=F3dulos seriam disponibilizados de acordo com as credenciais de autentica=E7=E3o, pensam= os em uma "mesa de menu", ou "Portal de Menu", que agruparia portlets de menu de acordo com a categoriza=E7=E3o dos itens, permitindo que essa lis= ta fosse constru=EDda dinamicamente. Desenhei um diagrama (em anexo) que ilustra como isso apareceria para o usu=E1rio. daniel |
From: Daniel R. <da...@ru...> - 2006-07-07 02:52:37
|
Em Qui, 2006-07-06 =E0s 19:48 -0300, Igor Sutton Lopes escreveu: > Geralmente =E9 muito mais complicado voc=EA fazer com uma GUI o que voc= =EA faz com um > interpretador HTML decente. Se voc=EA utilizar a mesma tecnologia para = o cliente, > na minha opini=E3o =E9 melhor. Nesse caso, para a discuss=E3o da caracter=EDstica em quest=E3o, tanto fa= z se =E9 implementado com GTKHTML ou com ncurses... O que importa =E9 que a esta=E7=E3o tem que ser atualizada e deve ter novas aplica=E7=F5es instal= adas automaticamente e n=E3o pode depender da rede sempre dispon=EDvel, voc=EA= pode utilizar janelas de conex=E3o para troca de informa=E7=F5es e para essa atualiza=E7=E3o... daniel |
From: Daniel R. <da...@ru...> - 2006-07-07 02:44:59
|
Em Qui, 2006-07-06 =E0s 19:39 -0300, Igor Sutton Lopes escreveu: > Creio que temos condi=E7=F5es de tornar isso transparente. A aplica=E7=E3= o cliente > (seja ela GUI, Web, ou outra m=EDdia qualquer) entrar=E1 em contato com= o servi=E7o > de localiza=E7=E3o de aplica=E7=F5es. Ele identificar=E1 o tipo de m=ED= dia utilizada, e > disponibilizar=E1 as informa=E7=F5es necess=E1rias para o aplicativo cl= iente > acess=E1-los. O cliente ent=E3o se responsabilizar=E1 por contactar as = aplica=E7=F5es, > conforme informa=E7=F5es passadas. Ok, correto, tecnicamente...=20 > Um =FAnico servi=E7o de autentica=E7=E3o seria suficiente para isso? Se= r=E1 pensado em > v=EDnculos de confian=E7a entre 'dom=EDnios' distintos? Em primeiro mom= ento, um > ponto =FAnico de autentica=E7=E3o/autoriza=E7=E3o parece suficiente. V=EDnculos de confian=E7a entre dom=EDnios =E9 certamente algo relevante,= e alguns mecanismos de autentica=E7=E3o possibilitam isso, como X509, por exemplo... > Ent=E3o, creio que teremos modelos para cada tipo de aplica=E7=E3o que = queira se > utilizar, e isso me lembra muito XSLT. A quest=E3o n=E3o =E9 apenas de exibir uma mesma interface de formas diferentes... (acho que cheguei ao ponto de confus=E3o)... A quest=E3o =E9= que cada um desses p=FAblicos, cada uma dessas interfaces, pode at=E9 prover funcionalidades que s=E3o exclusivas de cada um... Por exemplo... Em uma interface Web (no sentido que me referi no outro email) n=E3o faz sentido uma interface de digita=E7=E3o de nota fiscal, a= ssim como n=E3o faz sentido na interface GUI a forma de navega=E7=E3o entre as informa=E7=F5es que normalmente o hypertexto prov=EA. Lembrando mais uma = vez, n=E3o =E9 uma quest=E3o da tecnologia a ser usada, voc=EA pode muito bem = ter a interface web implementada com active desktop e a interface gui implementada com AJAX... Ent=E3o voltamos a pergunta inicial: Como essa interface funcionaria? (no sentido da intera=E7=E3o com o usu=E1rio, e n=E3o no sentido t=E9cnico) S= e f=F4ssemos fazer um prot=F3tipo, com que se pareceria? daniel |
From: Daniel R. <da...@ru...> - 2006-07-07 02:34:54
|
Em Qui, 2006-07-06 =E0s 19:49 -0300, Igor Sutton Lopes escreveu: > Mais uma d=FAvida: quais ser=E3o as m=EDdias clientes em potencial? > - web > - gui > - pda Sim. O foco do projeto nesse momento ser=E1 exatamente para esses tr=EAs p=FAblicos, sendo: Web: Entendido no sentido de portal, ou seja, no sentido de uma interface que privilegia a obten=E7=E3o de informa=E7=F5es (podendo ser implementado como o Mezzo, do SymphonyOs ou como um portal acessado por um browser) Gui: No sentido de favorecer a=E7=F5es operacionais, privilegiando a entr= ada de dados (podendo ser implementado como uma aplica=E7=E3o standalone ou c= om um mini-servidor-de-aplicacao e um rederizador html com AJAX) Pda: Ambiente restrito com acesso a poucas informa=E7=F5es e poucas intera=E7=F5es, normalmente com restri=E7=F5es no acesso =E0 rede e restr= i=E7=F5es de recurso de hardware. (Podemos deixar a quest=E3o tecnol=F3gica para um segundo momento...) daniel |
From: Igor S. L. <igo...@gm...> - 2006-07-06 22:49:40
|
Daniel Ruoso <da...@ru...> writes: > Ol=E1, > > Uma quest=E3o que ainda est=E1 em aberto para mim =E9 a quest=E3o de como= prover > um ambiente web integrado com um conjunto indefinido de composite > applications. Formulando melhor (izut++): > > "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos > atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1rio e= m um ou > mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente?" Mais uma d=FAvida: quais ser=E3o as m=EDdias clientes em potencial? - web - gui - pda? - ???? |
From: Igor S. L. <igo...@gm...> - 2006-07-06 22:47:56
|
Daniel Ruoso <da...@ru...> writes: > Em Qui, 2006-07-06 =E0s 18:55 -0300, Igor Sutton Lopes escreveu: >> Daniel Ruoso <da...@ru...> writes: >> > Uma caracter=EDstica importante, heradada da computa=E7=E3o pervasiva = =E9 a >> > id=E9ia de que o usu=E1rio n=E3o deva precisar interagir a respeito da >> > instala=E7=E3o de novas aplica=E7=F5es ou a disponibiliza=E7=E3o de no= vas vers=F5es de >> > aplica=E7=F5es existentes. >> Em que situa=E7=F5es seriam necess=E1rias aplica=E7=F5es sendo utilizada= s apenas no lado >> cliente, sem intera=E7=E3o com um servidor de aplica=E7=F5es? Loca=E7=F5= es remotas talvez? > > Loca=E7=F5es remotas s=E3o s=F3 o caso mais simples, mas insuficiencia ou= falha > de rede s=E3o outro caso, otimiza=E7=E3o de uso tamb=E9m justificam... Vamos listar ent=E3o: - loca=E7=F5es remotas, com acesso a rede prec=E1rio; - otimiza=E7=E3o de uso; - toler=E2ncia a falhas de rede (sincroniza=E7=E3o de dados); O que mais? > >> Uma id=E9ia que julgo interessante =E9 a utiliza=E7=E3o no lado cliente = um >> interpretador HTML, como o Gecko. Ele estaria acompanhado de um >> 'mini-servidor-de-aplica=E7=F5es' instalado no cliente. A distribui=E7= =E3o dos m=F3dulos >> seria feito atrav=E9s de um pacote (similar ao WAR). > > N=E3o =E9 melhor fazer logo a aplica=E7=E3o? voc=EA teria um peso para ro= dar um > interpretador html quando tudo que voc=EA queria era exibir um formul=E1r= io, > que o sistema operacional faz nativamente. O que ganhamos com isso? Geralmente =E9 muito mais complicado voc=EA fazer com uma GUI o que voc=EA = faz com um interpretador HTML decente. Se voc=EA utilizar a mesma tecnologia para o cl= iente, na minha opini=E3o =E9 melhor. Mais f=E1cil do que criar uma camada interme= di=E1ria, por exemplo. A n=E3o ser que o foco seja a utiliza=E7=E3o de computadores c= om poucos recursos. Se for este o caso, n=E3o podemos utilizar recursos avan=E7ados c= omo AJAX, sendo suficiente um interpretador HTML simples, como o GTKHTML. |
From: Igor S. L. <igo...@gm...> - 2006-07-06 22:38:53
|
Daniel Ruoso <da...@ru...> writes: > Em Qui, 2006-07-06 =E0s 18:54 -0300, Igor Sutton Lopes escreveu: >> Daniel Ruoso <da...@ru...> writes: >> > "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos >> > atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1ri= o em um ou >> > mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente= ?" >> Uma pista sobre o modo de disponibiliza=E7=E3o seria um 'localizador de = servi=E7os', >> que seria o respons=E1vel pela disponibiliza=E7=E3o dos endere=E7os das >> aplica=E7=F5es. > > Sim, mas isso =E9 parte da infraestrutura do servidor de aplica=E7=F5es, = n=E3o > da interface. A interface vai efetivamente localizar esses servi=E7os... a > quest=E3o =E9 como vai ser a experi=EAncia do usu=E1rio em rela=E7=E3o a = isso? Creio que temos condi=E7=F5es de tornar isso transparente. A aplica=E7=E3o = cliente (seja ela GUI, Web, ou outra m=EDdia qualquer) entrar=E1 em contato com o s= ervi=E7o de localiza=E7=E3o de aplica=E7=F5es. Ele identificar=E1 o tipo de m=EDdia = utilizada, e disponibilizar=E1 as informa=E7=F5es necess=E1rias para o aplicativo cliente acess=E1-los. O cliente ent=E3o se responsabilizar=E1 por contactar as apli= ca=E7=F5es, conforme informa=E7=F5es passadas. > >> > * Usu=E1rios an=F4nimos (sem credenciais) podem ter acesso a um conjun= to de >> > m=F3dulos tamb=E9m. >> Creio que cada aplica=E7=E3o deva ser respons=E1vel pela autoriza=E7=E3o= do >> usu=E1rio. > > A id=E9ia de ter a plataforma =E9 justamente prover um mecanismo onde ela > possa simplesmente dizer "usu=E1rio X tem acesso a Y", "usu=E1rio an=F4ni= mo > tem acesso a Z" e tudo acontecer de forma autom=E1tica. > > A quest=E3o =E9 que autentica=E7=E3o =E9 uma coisa que n=E3o varia muito,= pra falar > a verdade, a =FAnica coisa que varia s=E3o o formato das credenciais... a= cho > que o PAM do Unix e o JAAS do Java s=E3o um =F3timo exemplo de implementa= =E7=E3o > que pode ser seguido, no entanto, existe uma camada de aplica=E7=E3o que = =E9 > quem faz o qu=EA. Ter um diret=F3rio integrado de autoriza=E7=E3o me pare= ce uma > boa id=E9ia. Um =FAnico servi=E7o de autentica=E7=E3o seria suficiente para isso? Ser=E1= pensado em v=EDnculos de confian=E7a entre 'dom=EDnios' distintos? Em primeiro momento= , um ponto =FAnico de autentica=E7=E3o/autoriza=E7=E3o parece suficiente. [snip] > > A quest=E3o =E9 que se pararmos para pensar, vamos ver que, no mundo real, > quem utiliza a aplica=E7=E3o GUI =E9 a equipe operacional, que precisa dar > entrada nos sistemas de um grande volume de dados e que precisa de muita > agilidade para isso. (apenas lembrando que, pensando dessa forma, uma > aplica=E7=E3o AJAX =E9 uma aplica=E7=E3o GUI). Certo, ent=E3o temos que pensar neste p=FAblico tamb=E9m. > > No entanto, normalmente o p=FAblico que vai acessar uma aplica=E7=E3o web= (no > formato de um portal, talvez) normalmente precisa obter muito mais > informa=E7=F5es do que lan=E7ar. Nesse sentido, =E9 preciso uma interface > orientada a isso. > E neste p=FAblico tamb=E9m :) Ent=E3o, creio que teremos modelos para cada tipo de aplica=E7=E3o que quei= ra se utilizar, e isso me lembra muito XSLT. [snip] |
From: Daniel R. <da...@ru...> - 2006-07-06 22:32:18
|
Em Qui, 2006-07-06 =E0s 18:55 -0300, Igor Sutton Lopes escreveu: > Daniel Ruoso <da...@ru...> writes: > > Uma caracter=EDstica importante, heradada da computa=E7=E3o pervasiva= =E9 a > > id=E9ia de que o usu=E1rio n=E3o deva precisar interagir a respeito d= a > > instala=E7=E3o de novas aplica=E7=F5es ou a disponibiliza=E7=E3o de n= ovas vers=F5es de > > aplica=E7=F5es existentes. > Em que situa=E7=F5es seriam necess=E1rias aplica=E7=F5es sendo utilizad= as apenas no lado > cliente, sem intera=E7=E3o com um servidor de aplica=E7=F5es? Loca=E7=F5= es remotas talvez? Loca=E7=F5es remotas s=E3o s=F3 o caso mais simples, mas insuficiencia ou= falha de rede s=E3o outro caso, otimiza=E7=E3o de uso tamb=E9m justificam... > Uma id=E9ia que julgo interessante =E9 a utiliza=E7=E3o no lado cliente= um > interpretador HTML, como o Gecko. Ele estaria acompanhado de um > 'mini-servidor-de-aplica=E7=F5es' instalado no cliente. A distribui=E7=E3= o dos m=F3dulos > seria feito atrav=E9s de um pacote (similar ao WAR). N=E3o =E9 melhor fazer logo a aplica=E7=E3o? voc=EA teria um peso para ro= dar um interpretador html quando tudo que voc=EA queria era exibir um formul=E1r= io, que o sistema operacional faz nativamente. O que ganhamos com isso? daniel |
From: Daniel R. <da...@ru...> - 2006-07-06 22:16:03
|
Em Qui, 2006-07-06 =E0s 19:06 -0300, Daniel Ruoso escreveu: > Em Qui, 2006-07-06 =E0s 18:54 -0300, Igor Sutton Lopes escreveu: > > Existem alguns projetos como o Symphony OS que podem nos dar algumas > > dicas, pois eliminam a utiliza=E7=E3o de menus, e disponibiliza as > > informa=E7=F5es como se fosse um 'active desktop'. > http://www.symphonyos.com/ > =C9 uma proposta interessante, merece investiga=E7=E3o...=20 Apenas para registro: http://www.symphonyos.com/wiki/index.php/The_Mezzo_Desktop Na verdade o que estava falando era do Mezzo, e n=E3o do Symphony. Tem um "graypaper" sobre o mezzo nessa url a=ED... vai pra biblioteca tamb=E9m..= . daniel |
From: Daniel R. <da...@ru...> - 2006-07-06 22:06:21
|
Em Qui, 2006-07-06 =E0s 18:54 -0300, Igor Sutton Lopes escreveu: > Daniel Ruoso <da...@ru...> writes: > > "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtid= os > > atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1r= io em um ou > > mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerent= e?" > Uma pista sobre o modo de disponibiliza=E7=E3o seria um 'localizador de= servi=E7os', > que seria o respons=E1vel pela disponibiliza=E7=E3o dos endere=E7os das > aplica=E7=F5es. Sim, mas isso =E9 parte da infraestrutura do servidor de aplica=E7=F5es, = n=E3o da interface. A interface vai efetivamente localizar esses servi=E7os... = a quest=E3o =E9 como vai ser a experi=EAncia do usu=E1rio em rela=E7=E3o a = isso? > > * Usu=E1rios an=F4nimos (sem credenciais) podem ter acesso a um conju= nto de > > m=F3dulos tamb=E9m. > Creio que cada aplica=E7=E3o deva ser respons=E1vel pela autoriza=E7=E3= o do > usu=E1rio. A id=E9ia de ter a plataforma =E9 justamente prover um mecanismo onde ela possa simplesmente dizer "usu=E1rio X tem acesso a Y", "usu=E1rio an=F4ni= mo tem acesso a Z" e tudo acontecer de forma autom=E1tica. A quest=E3o =E9 que autentica=E7=E3o =E9 uma coisa que n=E3o varia muito,= pra falar a verdade, a =FAnica coisa que varia s=E3o o formato das credenciais... a= cho que o PAM do Unix e o JAAS do Java s=E3o um =F3timo exemplo de implementa= =E7=E3o que pode ser seguido, no entanto, existe uma camada de aplica=E7=E3o que = =E9 quem faz o qu=EA. Ter um diret=F3rio integrado de autoriza=E7=E3o me pare= ce uma boa id=E9ia. > > * O Usu=E1rio pode visualizar mais de uma informa=E7=E3o ao mesmo tem= po > > (portal e portlets s=E3o uma pista, mas como decidir o que aparece on= de?). > Isto n=E3o fa=E7o id=E9ia ainda. Tem nos materiais que mandei :), mas de qualquer forma, o JBoss Portals e o Apache Portals s=E3o bons exemplos. > > * Em um ambiente GUI, isso seria facilmente resolvido com a constru=E7= =E3o > > din=E2mica de uma hierarquia de menus, uma vez que na interface GUI a > > necessidade =E9 muito mais de entrada de informa=E7=F5es, enquanto a = interface > > Web tem como caracter=EDstica (pensando no usu=E1rio potencial de uma= e de > > outra) a obten=E7=E3o de informa=E7=F5es, de forma que uma hierarquia= de menus =E9 > > sub-otimizada para esse fim. > A principal quest=E3o =E9: queremos que as informa=E7=F5es exibidas par= a uma aplica=E7=E3o > se pare=E7a com uma GUI? Seria realmente sub-otimizada? A quest=E3o =E9 que se pararmos para pensar, vamos ver que, no mundo real= , quem utiliza a aplica=E7=E3o GUI =E9 a equipe operacional, que precisa da= r entrada nos sistemas de um grande volume de dados e que precisa de muita agilidade para isso. (apenas lembrando que, pensando dessa forma, uma aplica=E7=E3o AJAX =E9 uma aplica=E7=E3o GUI). No entanto, normalmente o p=FAblico que vai acessar uma aplica=E7=E3o web= (no formato de um portal, talvez) normalmente precisa obter muito mais informa=E7=F5es do que lan=E7ar. Nesse sentido, =E9 preciso uma interface orientada a isso. > Voc=EA tem em mente algo que considere satisfat=F3rio? Na verdade ainda n=E3o... como eu disse, a pista que eu tenho =E9 o esque= ma de portais e portlets, mas ainda n=E3o sei direito como isso funcionaria... > Existem alguns projetos como o Symphony OS que podem nos dar algumas > dicas, pois eliminam a utiliza=E7=E3o de menus, e disponibiliza as > informa=E7=F5es como se fosse um 'active desktop'. http://www.symphonyos.com/ =C9 uma proposta interessante, merece investiga=E7=E3o...=20 Uma pergunta que podemos nos fazer =E9: Quais as semelhan=E7as entre essa proposta e um portal? Que solu=E7=F5es ela traz que normalmente n=E3o encontramos em um portal? daniel |
From: Igor S. L. <igo...@gm...> - 2006-07-06 21:55:19
|
Daniel Ruoso <da...@ru...> writes: > Ol=E1, > > Uma caracter=EDstica importante, heradada da computa=E7=E3o pervasiva =E9= a > id=E9ia de que o usu=E1rio n=E3o deva precisar interagir a respeito da > instala=E7=E3o de novas aplica=E7=F5es ou a disponibiliza=E7=E3o de novas= vers=F5es de > aplica=E7=F5es existentes. Em que situa=E7=F5es seriam necess=E1rias aplica=E7=F5es sendo utilizadas a= penas no lado cliente, sem intera=E7=E3o com um servidor de aplica=E7=F5es? Loca=E7=F5es = remotas talvez? Uma id=E9ia que julgo interessante =E9 a utiliza=E7=E3o no lado cliente um interpretador HTML, como o Gecko. Ele estaria acompanhado de um 'mini-servidor-de-aplica=E7=F5es' instalado no cliente. A distribui=E7=E3o = dos m=F3dulos seria feito atrav=E9s de um pacote (similar ao WAR). |
From: Igor S. L. <igo...@gm...> - 2006-07-06 21:54:36
|
Daniel Ruoso <da...@ru...> writes: > Ol=E1, > > Uma quest=E3o que ainda est=E1 em aberto para mim =E9 a quest=E3o de como= prover > um ambiente web integrado com um conjunto indefinido de composite > applications. Formulando melhor (izut++): > > "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos > atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1rio e= m um ou > mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente?" Uma pista sobre o modo de disponibiliza=E7=E3o seria um 'localizador de ser= vi=E7os', que seria o respons=E1vel pela disponibiliza=E7=E3o dos endere=E7os das aplica=E7=F5es. > > * Usu=E1rios an=F4nimos (sem credenciais) podem ter acesso a um conjunto = de > m=F3dulos tamb=E9m. Creio que cada aplica=E7=E3o deva ser respons=E1vel pela autoriza=E7=E3o do usu=E1rio. > * O Usu=E1rio pode visualizar mais de uma informa=E7=E3o ao mesmo tempo > (portal e portlets s=E3o uma pista, mas como decidir o que aparece onde?). Isto n=E3o fa=E7o id=E9ia ainda. > * Em um ambiente GUI, isso seria facilmente resolvido com a constru=E7=E3o > din=E2mica de uma hierarquia de menus, uma vez que na interface GUI a > necessidade =E9 muito mais de entrada de informa=E7=F5es, enquanto a inte= rface > Web tem como caracter=EDstica (pensando no usu=E1rio potencial de uma e de > outra) a obten=E7=E3o de informa=E7=F5es, de forma que uma hierarquia de = menus =E9 > sub-otimizada para esse fim. A principal quest=E3o =E9: queremos que as informa=E7=F5es exibidas para um= a aplica=E7=E3o se pare=E7a com uma GUI? Seria realmente sub-otimizada? Voc=EA tem em mente= algo que considere satisfat=F3rio? Existem alguns projetos como o Symphony OS que podem nos dar algumas dicas, pois eliminam a utiliza=E7=E3o de menus, e disponibiliza as informa=E7=F5es como se fosse um 'active desktop'. > > Como eu disse, essa quest=E3o est=E1 em aberto... > > daniel > > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job ea= sier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Perl-oak-discuss-br mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-oak-discuss-br ---------- |
From: Igor S. L. <igo...@gm...> - 2006-07-06 21:34:46
|
Daniel Ruoso <da...@ru...> writes: > Ol=E1, > > Uma caracter=EDstica importante, heradada da computa=E7=E3o pervasiva =E9= a > id=E9ia de que o usu=E1rio n=E3o deva precisar interagir a respeito da > instala=E7=E3o de novas aplica=E7=F5es ou a disponibiliza=E7=E3o de novas= vers=F5es de > aplica=E7=F5es existentes. Em que situa=E7=F5es seriam necess=E1rias aplica=E7=F5es sendo utilizadas a= penas no lado cliente, sem intera=E7=E3o com um servidor de aplica=E7=F5es? Loca=E7=F5es = remotas talvez? Uma id=E9ia que julgo interessante =E9 a utiliza=E7=E3o no lado cliente um interpretador HTML, como o Gecko. Ele estaria acompanhado de um 'mini-servidor-de-aplica=E7=F5es' instalado no cliente. A distribui=E7=E3o = dos m=F3dulos seria feito atrav=E9s de um pacote (similar ao WAR). |
From: Igor S. L. <igo...@gm...> - 2006-07-06 21:34:08
|
Daniel Ruoso <da...@ru...> writes: > Ol=E1, > > Uma quest=E3o que ainda est=E1 em aberto para mim =E9 a quest=E3o de como= prover > um ambiente web integrado com um conjunto indefinido de composite > applications. Formulando melhor (izut++): > > "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos > atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1rio e= m um ou > mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente?" Uma pista sobre o modo de disponibiliza=E7=E3o seria um 'localizador de ser= vi=E7os', que seria o respons=E1vel pela disponibiliza=E7=E3o dos endere=E7os das aplica=E7=F5es. > > * Usu=E1rios an=F4nimos (sem credenciais) podem ter acesso a um conjunto = de > m=F3dulos tamb=E9m. Creio que cada aplica=E7=E3o deva ser respons=E1vel pela autoriza=E7=E3o do usu=E1rio. > * O Usu=E1rio pode visualizar mais de uma informa=E7=E3o ao mesmo tempo > (portal e portlets s=E3o uma pista, mas como decidir o que aparece onde?). Isto n=E3o fa=E7o id=E9ia ainda. > * Em um ambiente GUI, isso seria facilmente resolvido com a constru=E7=E3o > din=E2mica de uma hierarquia de menus, uma vez que na interface GUI a > necessidade =E9 muito mais de entrada de informa=E7=F5es, enquanto a inte= rface > Web tem como caracter=EDstica (pensando no usu=E1rio potencial de uma e de > outra) a obten=E7=E3o de informa=E7=F5es, de forma que uma hierarquia de = menus =E9 > sub-otimizada para esse fim. A principal quest=E3o =E9: queremos que as informa=E7=F5es exibidas para um= a aplica=E7=E3o se pare=E7a com uma GUI? Seria realmente sub-otimizada? Voc=EA tem em mente= algo que considere satisfat=F3rio? Existem alguns projetos como o Symphony OS que podem nos dar algumas dicas, pois eliminam a utiliza=E7=E3o de menus, e disponibiliza as informa=E7=F5es como se fosse um 'active desktop'. > > Como eu disse, essa quest=E3o est=E1 em aberto... > > daniel > > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job ea= sier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Perl-oak-discuss-br mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-oak-discuss-br |
From: Igor S. L. <igo...@gm...> - 2006-07-06 21:19:57
|
Daniel Ruoso <da...@ru...> writes: > Ol=E1, > > Uma caracter=EDstica importante, heradada da computa=E7=E3o pervasiva =E9= a > id=E9ia de que o usu=E1rio n=E3o deva precisar interagir a respeito da > instala=E7=E3o de novas aplica=E7=F5es ou a disponibiliza=E7=E3o de novas= vers=F5es de > aplica=E7=F5es existentes. Em que situa=E7=F5es seriam necess=E1rias aplica=E7=F5es sendo utilizadas a= penas no lado cliente, sem intera=E7=E3o com um servidor de aplica=E7=F5es? Loca=E7=F5es = remotas talvez? Uma id=E9ia que julgo interessante =E9 a utiliza=E7=E3o no lado cliente um interpretador HTML, como o Gecko. Ele estaria acompanhado de um 'mini-servidor-de-aplica=E7=F5es' instalado no cliente. A distribui=E7=E3o = dos m=F3dulos seria feito atrav=E9s de um pacote (similar ao WAR). |
From: Igor S. L. <igo...@gm...> - 2006-07-06 21:19:49
|
Daniel Ruoso <da...@ru...> writes: > Ol=E1, > > Uma quest=E3o que ainda est=E1 em aberto para mim =E9 a quest=E3o de como= prover > um ambiente web integrado com um conjunto indefinido de composite > applications. Formulando melhor (izut++): > > "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos > atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1rio e= m um ou > mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente?" Uma pista sobre o modo de disponibiliza=E7=E3o seria um 'localizador de ser= vi=E7os', que seria o respons=E1vel pela disponibiliza=E7=E3o dos endere=E7os das aplica=E7=F5es. > > * Usu=E1rios an=F4nimos (sem credenciais) podem ter acesso a um conjunto = de > m=F3dulos tamb=E9m. Creio que cada aplica=E7=E3o deva ser respons=E1vel pela autoriza=E7=E3o do usu=E1rio. > * O Usu=E1rio pode visualizar mais de uma informa=E7=E3o ao mesmo tempo > (portal e portlets s=E3o uma pista, mas como decidir o que aparece onde?). Isto n=E3o fa=E7o id=E9ia ainda. > * Em um ambiente GUI, isso seria facilmente resolvido com a constru=E7=E3o > din=E2mica de uma hierarquia de menus, uma vez que na interface GUI a > necessidade =E9 muito mais de entrada de informa=E7=F5es, enquanto a inte= rface > Web tem como caracter=EDstica (pensando no usu=E1rio potencial de uma e de > outra) a obten=E7=E3o de informa=E7=F5es, de forma que uma hierarquia de = menus =E9 > sub-otimizada para esse fim. A principal quest=E3o =E9: queremos que as informa=E7=F5es exibidas para um= a aplica=E7=E3o se pare=E7a com uma GUI? Seria realmente sub-otimizada? Voc=EA tem em mente= algo que considere satisfat=F3rio? Existem alguns projetos como o Symphony OS que podem nos dar algumas dicas, pois eliminam a utiliza=E7=E3o de menus, e disponibiliza as informa=E7=F5es como se fosse um 'active desktop'. > > Como eu disse, essa quest=E3o est=E1 em aberto... > > daniel > > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job ea= sier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Perl-oak-discuss-br mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-oak-discuss-br |
From: Daniel R. <da...@ru...> - 2006-07-06 20:41:20
|
Ol=E1, Uma caracter=EDstica importante, heradada da computa=E7=E3o pervasiva =E9= a id=E9ia de que o usu=E1rio n=E3o deva precisar interagir a respeito da instala=E7=E3o de novas aplica=E7=F5es ou a disponibiliza=E7=E3o de novas= vers=F5es de aplica=E7=F5es existentes. No entanto, as novas aplica=E7=F5es ou vers=F5es n=E3o devem ser executad= as sem a certifica=E7=E3o (X509 somente?) de uma autoridade espec=EDfica (setor = de TI da empresa, por exemplo). Pensando no mundo Perl, =E9 poss=EDvel pensar a partir do m=F3dulo lib::h= ttp (http://search.cpan.org/~gmpassos/lib-http-0.01/lib/lib/http.pm ). Um poss=EDvel exemplo de uso seria: use lib::certified::x509 trust =3D> "/etc/trusted_certifieds", path =3D> "http://servidor.de.modulos/"; ou use lib::certified::x509 trust =3D> "/etc/trusted_certifieds", path =3D> "/caminho/para/modulos/inseguros/"; De forma que o primeiro caso, ele iria buscar os m=F3dulos na rede e no segundo em uma pasta local. Caso o certificado n=E3o seja validado, os m=F3dulos na pasta n=E3o ser=E3o carregados. Deu pra entender? daniel |
From: Daniel R. <da...@ru...> - 2006-07-06 20:22:51
|
Ol=E1, Uma quest=E3o que ainda est=E1 em aberto para mim =E9 a quest=E3o de como= prover um ambiente web integrado com um conjunto indefinido de composite applications. Formulando melhor (izut++): "Como disponibilizar um conjunto de m=F3dulos de aplica=E7=E3o, obtidos atrav=E9s das credenciais de autentica=E7=E3o fornecidas pelo usu=E1rio e= m um ou mais servidores de aplica=E7=E3o em um ambiente web =FAnico e coerente?" * Usu=E1rios an=F4nimos (sem credenciais) podem ter acesso a um conjunto = de m=F3dulos tamb=E9m. * O Usu=E1rio pode visualizar mais de uma informa=E7=E3o ao mesmo tempo (portal e portlets s=E3o uma pista, mas como decidir o que aparece onde?)= . * Em um ambiente GUI, isso seria facilmente resolvido com a constru=E7=E3= o din=E2mica de uma hierarquia de menus, uma vez que na interface GUI a necessidade =E9 muito mais de entrada de informa=E7=F5es, enquanto a inte= rface Web tem como caracter=EDstica (pensando no usu=E1rio potencial de uma e d= e outra) a obten=E7=E3o de informa=E7=F5es, de forma que uma hierarquia de = menus =E9 sub-otimizada para esse fim. Como eu disse, essa quest=E3o est=E1 em aberto... daniel |
From: Daniel R. <da...@ru...> - 2006-07-06 20:13:26
|
Mais uma vez aqui estou eu... Precisamos tamb=E9m trabalhar algumas quest=F5es conceituais, tanto as qu= e j=E1 conhecemos quanto as que ainda iremos perceber. Uma quest=E3o conceitual =E9 anterior a uma quest=E3o t=E9cnica, e por isso =E9 indepen= dente de implementa=E7=E3o. Da mesma forma, vou abrir um diret=F3rio QuestoesConceituais e vamos trabalhar com um thread por quest=E3o com prefixo [CONCEITO] no assunto. daniel |
From: Daniel R. <da...@ru...> - 2006-07-06 20:09:16
|
Ol=E1 de novo mais uma vez... Estou fazendo emails separados porque s=E3o assuntos separados mesmo...=20 Um outro aspecto da arquitetura s=E3o caracter=EDsticas t=E9cnicas que a = gente j=E1 sabe previamente que s=E3o nececess=E1rias, e que n=E3o precisam est= ar explicitadas nos cen=E1rios de uso. Por exemplo, poder autenticar utilizando v=E1rias credenciais (ident, kerberos, X509 etc) =E9 uma caracter=EDstica t=E9cnica que n=E3o precisa = ser listada nos cen=E1rios de uso se deixarmos sua necessidade expl=EDcita previamente. Dessa forma, vou abrir um outro diret=F3rio no CVS com o nome de CaracteristicasTecnicas para documentarmos isso. Como no caso dos cenarios, vamos trabalhar um thread para cada caracter=EDstica utilizando o prefixo [CARACT] no assunto. daniel |
From: Daniel R. <da...@ru...> - 2006-07-06 19:57:11
|
Ol=E1 de novo... A =FAnica metodologia que eu conhe=E7o para pensar uma arquitetura de software =E9 pensar os cen=E1rios de uso no qual o software seria utiliza= do para poder testar os conceitos que estivermos pensando. Para facilitar o trabalho de documentar esses cen=E1rios, abri um espa=E7= o no CVS do perl-oak para esse trabalho de planejamento. Dentro dele j=E1 criei um diret=F3rio Cenarios onde podemos catalogar esses cenarios. Quem quiser manipular diretamente no CVS, basta ter uma conta no sourceforge que eu autorizo, caso contr=E1rio, estarei tentando consolida= r os cen=E1rios que discutirmos na lista nesse diret=F3rio. Para visualiza=E7=E3o, mesmo quem n=E3o tiver CVS e coisa e tal, pode ser atrav=E9s da Web, na URL abaixo... http://perl-oak.cvs.sourceforge.net/perl-oak/Oak/Oak2-Planning/ Para facilitar a discuss=E3o, vamos abrir um thread novo para cada proposta de cen=E1rio que lan=E7armos e incluir [CENARIO] no assunto, por exemplo: "[CENARIO] Sistema de PDV em rede inst=E1vel". Depois cada um desses cen=E1rios ter=E1 um arquivo no CVS com o seu formato (=E9 bom no = CVS porque teremos o hist=F3rico das modifica=E7=F5es no cenario)... daniel |
From: Daniel R. <da...@ru...> - 2006-07-06 18:17:21
|
Beleza, Vamos come=E7ar os trabalhos... Acho que era legal come=E7ar com algumas leituras que eu fiz e que eu ach= o que seriam legais para a gente sintonizar as id=E9ias... Seria legal quem tiver outras refer=EAncias de leitura poder passar tamb=E9m... Especifica=E7=E3o da W3C para arquitetura de Web Services http://www.w3.org/TR/ws-arch/ Especifica=E7=E3o da OASIS para arquitetura de Web Services para Portlets Remotos http://www.oasis-open.org/committees/download.php/18617/wsrp-2.0-spec-pr-= 01.html Architectural Styles and the Design of Network-based Software Architectures http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Web Services Context Service Specification http://developers.sun.com/techtopics/webservices/wscaf/wsctx.pdf Web Services Description Language (WSDL) 1.1 http://www.w3.org/TR/wsdl Enterprise Services Architecture (Dan Woods) ISBN: 0596005512 Packaged Composite Applications: An O'Reilly Field Guide to Enterprise Software (Dan Woods) ISBN: 0596005520 OASIS -- Web Services Coordination Framework Specification -- Web Services Composite Application Framework http://www.oasis-open.org/committees/documents.php?wg_abbrev=3Dws-caf Daniel Ruoso |