Marshal o load?

Hola a tutti!

Presento subito il mio dubbio/problema:

Voglio fare un applicazione in ruby client/server che permette al client
di
utilizzare le classi definite nel server per poi inoltrare richieste al
mondo
esterno…
cerco di spiegare meglio quello che voglio fare:

  • server:
    Contiene varie classi (tutte condividono il metodo .manda) e dovrebbe
    restituire un oggetto di una di queste, che non fa altro che fare delle
    richieste HTTP a vari siti

  • client:
    Dovrebbe prendere quest’oggetto già istanziato/riempito e richiamare il
    metodo .manda

una delle soluzioni più pulite mi è sembrata Drb(+Marshal) ma da quello che ho
capito/sperimentato drb si limita a passare un riferimento alla classe
del
server oppure una copia Marshalosa, cosa che a me non serve…

Una soluzione sporca, molto sporca, sarebbe quella di mettere a
disposizione
da qualche parte i file contenenti le varie classi e far fare il load
dal
client… ma non mi piace affatto.

Sapete suggerirmi qualche soluzione?

grasssie!

– Calogero Lo Leggio [email protected] wrote:

  • server:
    Contiene varie classi (tutte condividono il metodo
    .manda) e dovrebbe
    restituire un oggetto di una di queste, che non fa
    altro che fare delle
    richieste HTTP a vari siti

  • client:
    Dovrebbe prendere quest’oggetto già
    istanziato/riempito e richiamare il
    metodo .manda

urrah per reinventare corba[0]!

una delle soluzioni più pulite mi è sembrata
Drb(+Marshal) ma da quello che ho
capito/sperimentato drb si limita a passare un
riferimento alla classe del
server oppure una copia Marshalosa, cosa che a me
non serve…

la copia marshalled mi sembra proprio quel che ti
serve, perché non va bene?

Quali sono i dati che il server deve inserire?
Se i dati sono semplici e non hanno riferimenti lato
server sarebbe più semplice:

data = Client.get_data_from_server()
obj = Client::SomeObject.new(data)
obj.foo()

Ma mi pare di capire che tu devi scaricare proprio il
codice delle classi, giusto?
Perché?E’ possibile trasformare i “comportamenti” che tu vuoi
scaricare attraverso le classi in semplici dati[1]?

Una soluzione sporca, molto sporca, sarebbe quella
di mettere a disposizione
da qualche parte i file contenenti le varie classi e
far fare il load dal
client… ma non mi piace affatto.

perché no? gli url sono sotto il tuo controllo quindi
non c’è nessuna differenza rispetto a usare un
processo remoto tranne che risparmi un server perché
probabilmente un demone http/ftp ce l’hai
già.
[0] Ok rmi, misà che questo è il famoso class
downloading :slight_smile:
[1] lisp, how much I miss thee


Goto 10: http://www.goto10.it
blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info

  ___________________________________________________________

Support the World Aids Awareness campaign this month with Yahoo! For
Good http://uk.promotions.yahoo.com/forgood/

— Fernando V. [email protected] wrote:

Il client non ha idea delle classi che vengono
definite lato server e
queste sono completamente gestite dal server.

ok, ma per fare cosa? Se le classi definissero, ad
esmepio, calcoli matematici da fare, vi conviene usare
una implementazione di MapReduce in ruby. Se le classi
definiscono IP da pingare per una specie di heartbeat
potee soprrimere la classe e trasmettere i soli dati.

Sospetto (sospettiamo?) che quello a cui vogliamo
arrivare sia
possibile, in particolare ho trovato sul web vari
riferimenti a
DRbObject.new, secondo certa documentazione sarebbe
possibile usare il
primo argomento per mappare un oggetto locale (cioè
appartenente al
client) in qualche modo, ma in tutti i tutorial si
trova impostato a
nil, e la rdoc non spiega una mazza.

ù
Ok, e quindi non vi è sufficiente nemmeno il
marshalling, perché le classi non sono serializzabili.

Il problema è che in DRb liscio o viene serializzato
l’oggetto (marshalling e non va bene, basta non usare
DrbUndumped) o si ha un riferimento remoto ( e non va
bene perché vuoi il lavoro sui client).

Tutto quel che non è serializzabile (classi, proc,
singleton, continuation etc) resta da una parte e
basta.

Il valore passato come “nil” a DrbObject.new non credo
faccia quel che volete, AFAIR serve per creare un
proxy verso un oggetto locale invece che remoto
(potrei ricordare male però).

Tornando alla domanda della mail precedente: cosa c’è
che non va nel prendere semplicemente i file da un url http/ftp?

  __________________________________________________________

Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

On Mon, Feb 18, 2008 at 03:28:27PM +0100, Calogero Lo Leggio wrote:

Hola a tutti!

Presento subito il mio dubbio/problema:

.gsub! ‘mio’, ‘nostro’ # :slight_smile:

Integro con alcune precisazioni così magari do un’idea un pò più precisa
di quello che stiamo facendo:

Voglio fare un applicazione in ruby client/server che permette al client di
utilizzare le classi definite nel server per poi inoltrare richieste al mondo
esterno…

Il client non ha idea delle classi che vengono definite lato server e
queste sono completamente gestite dal server.

cerco di spiegare meglio quello che voglio fare:

  • server:
    Contiene varie classi (tutte condividono il metodo .manda) e dovrebbe
    restituire un oggetto di una di queste, che non fa altro che fare delle
    richieste HTTP a vari siti

  • client:
    Dovrebbe prendere quest’oggetto già istanziato/riempito e richiamare il
    metodo .manda

Senza sapere quasi nulla della classe definita dal server, ovvero il
client sa solo che la classe ritornata ha un metodo .manda, e
probabilmente altri (che però non gli interessano in quanto non li userÃ
mai).

una delle soluzioni più pulite mi è sembrata Drb(+Marshal) ma da quello che ho
capito/sperimentato drb si limita a passare un riferimento alla classe del
server oppure una copia Marshalosa, cosa che a me non serve…

Siamo riusciti ad allocare oggetti tramite DRb, ma gli oggetti vengono
istanziati sul server, a noi serve che gli oggetti prendano vita sul
client.

Sospetto (sospettiamo?) che quello a cui vogliamo arrivare sia
possibile, in particolare ho trovato sul web vari riferimenti a
DRbObject.new, secondo certa documentazione sarebbe possibile usare il
primo argomento per mappare un oggetto locale (cioè appartenente al
client) in qualche modo, ma in tutti i tutorial si trova impostato a
nil, e la rdoc non spiega una mazza.

Ecco del codice di esempio:

#########################

server.rb

require ‘drb/drb’

class Cpoj
include DRb::DRbUndumped

mostra dove viene istanziato l’oggetto

def initialize()
puts “i am a #{self.class} object (#{self.object_id}) born on #{$$}”
end

esegue il lavoro sporco

def work(string)
puts “i am working on #{$$}, arg was #{string}”
return “i have worked”
end
end

associa la classe Cpoj al servizio

DRb.start_service ‘druby://server:6666’, Cpoj

puts “Service started at #{DRb.uri}”
DRb.thread.join

#########################

client.rb

require ‘drb/drb’

server=DRbObject.new_with_uri ‘druby://server:6666’

puts “i am the client: #{$$}”

l’oggetto viene allocato sul server !

the_cpoj=server.new

puts “the worker returned “#{the_cpoj.work ‘testo passato al
metodo’}””

Fernando V. wrote:

On Mon, Feb 18, 2008 at 03:28:27PM +0100, Calogero Lo Leggio wrote:

Siamo riusciti ad allocare oggetti tramite DRb, ma gli oggetti vengono
istanziati sul server, a noi serve che gli oggetti prendano vita sul
client.

In altre parole: il vostro server è un repository di codice, che
dev’essere scaricato dai client ed eseguito in locale.

A logica, se il codice deve girare sul client, bisogna che il codice
prima arrivi al client. Mi attendo quindi che il server debba in qualche
modo trasmettere al client tutte le classi necessarie e poi il client le
debba caricare ed eseguire il metodo .manda di quella che gli interessa.
Il tutto può avvenire con una eval o con l’esecuzione di un file
scaricato dal server o probabilmente in mille altri modi.

Sospetto (sospettiamo?) che quello a cui vogliamo arrivare sia
possibile, in particolare ho trovato sul web vari riferimenti a
DRbObject.new, secondo certa documentazione sarebbe possibile usare il
primo argomento per mappare un oggetto locale (cioè appartenente al
client) in qualche modo, ma in tutti i tutorial si trova impostato a
nil, e la rdoc non spiega una mazza.

Esattamente, questo è il problema di tante rdoc… Dal poco che si
capisce (intuisce?) mi parrebbe che il primo argomento serva per passare
un oggetto dal client al server ma per esserne certi bisognerebbe
studiarsi il sorgente di DRb e fare un po’ di prove. Non sarebbe però
quel che ti serve.

Paolo

Il 19/2/2008 09:22 gabriele renzi ha scritto:

ok, ma per fare cosa? Se le classi definissero, ad
esmepio, calcoli matematici da fare, vi conviene usare
una implementazione di MapReduce in ruby. Se le classi
definiscono IP da pingare per una specie di heartbeat
potee soprrimere la classe e trasmettere i soli dati.

già… ma sono dei dati/metodi complessi da serializzare a mano, e poi se
un
giorno volessi farlo utilizzerei SOAP

Il problema è che in DRb liscio o viene serializzato
l’oggetto (marshalling e non va bene, basta non usare
DrbUndumped) o si ha un riferimento remoto ( e non va
bene perché vuoi il lavoro sui client).

Tutto quel che non è serializzabile (classi, proc,
singleton, continuation etc) resta da una parte e
basta.

Era quello che temevo/pensavo… ma volevo una conferma attendibile :wink:

Tornando alla domanda della mail precedente: cosa c’è
che non va nel prendere semplicemente i file da un url http/ftp?

Mi sembrava una soluzione molto sporca… però riflettendoci…
potrei utilizzare un repository con le varie classi e cercare di
gestirle al
meglio(magari mettendo i nomi delle classi in un db e scegliere la
classe in
base a vari criteri) dicendo semplicemente al client di includere il
codice
ed eseguirlo.

Speravo di poterlo fare in qualche altro modo… ma anche questo va
benone.

grazie a tutti!

Siamo riusciti ad allocare oggetti tramite DRb, ma gli oggetti vengono
istanziati sul server, a noi serve che gli oggetti prendano vita sul
client.

In altre parole: il vostro server è un repository di codice, che
dev’essere scaricato dai client ed eseguito in locale.

A logica, se il codice deve girare sul client, bisogna che il codice
prima arrivi al client. Mi attendo quindi che il server debba in qualche
modo trasmettere al client tutte le classi necessarie e poi il client le
debba caricare ed eseguire il metodo .manda di quella che gli interessa.
Il tutto può avvenire con una eval o con l’esecuzione di un file
scaricato dal server o probabilmente in mille altri modi.

sì il tuo problema (se ho capito bene) è la mancanza della possibilitÃ
di caricare lib durante l’esecuzione.

Io lo risolverei così:

  • Mi scarico il file .rb che mi serve
  • Lancio un nuovo thread sul client che ricarichi l’enviroment e quindi
    anche la nuova lib .rb
  • Lavoro con il processo in locale invece che quello in remoto…

Era questo che volevi fare?

On Feb 19, 2008 12:09 PM, Calogero Lo Leggio [email protected]
wrote:

Il 19/2/2008 09:22 gabriele renzi ha scritto:

Tornando alla domanda della mail precedente: cosa c’è
che non va nel prendere semplicemente i file da un url http/ftp?

Mi sembrava una soluzione molto sporca… però riflettendoci…

considerazioni di sicurezza a parte (immagino sia un sistema
“controllato”
in cui ad esempio il codice eseguibile non puo entrare “liberamente” nel
server e da questo ai client), basta che tu consideri il codice come
dati da
memorizzare e trasmettere, non e’ detto che debbano essere su file
system,
ne che debbano essere trasmessi via http/ftp (anche se io userei un
protocollo standard, non fosse altro che per la possibilita di sfruttare
la
miriade di strumenti e librerie gia sviluppati)

potrei utilizzare un repository con le varie classi e cercare di gestirle
al
meglio(magari mettendo i nomi delle classi in un db e scegliere la classe
in
base a vari criteri) dicendo semplicemente al client di includere il
codice
ed eseguirlo.

se non ricordo male proprio in lista qualcuno mesi fa aveva parlato di
una
variazione sul tema delle wiki in cui le pagine erano “eseguibili”…

ciao,
Luca