Re: [Fresco-devel] network transparency

many thanx

On Thu, Jul 17, 2003 at 05:23:41PM -0700, Nathaniel Smith wrote:
> On Thu, Jul 17, 2003 at 08:39:54PM +0200, cinap_lenrek wrote:
> > hi
> > 
> > imho... fresco is not very network-transparent yet. for example... images have
> > to be stored on the servers side... i think to write a client-lib that
> > for exaple loads the image-file... and transfair it to the server with corba
> > is not a good idea... because you then have to write wrapper-libs for other
> > programing-languages... and you will lose the "all-you-need-is-an-orb"-feature.
> > 
> > what is planed to solve this problem?

> There is no problem, I think.  Images don't _have_ to be stored on the
> server side, but it makes things faster if you do so, and so we
> recommend it.  It's fairly easy to get an image into the server; just
> call RasterKit::create_empty_raster, then call Raster::load_data on
> the returned Raster object, passing in PNG data as an array of bytes.

> The API could use some work; create_empty_raster requires that the
> caller have parsed the PNG header, and the whole system assumes that
> you get your data into PNG format.  But this is just tweaking; it
> wouldn't be all that hard to create a
> RasterKit::create_raster_from_data method, that could guess at the
> image file format or something.
that sounds good :)
i will try it next time...

> > my idea is to provide something like a localServer, that provides corba-objects
> > to handle this kind of problems. (transfairing big blocks of data to the server)
> > maybe providing routines for bypassing corba as the transfair-channel.
> > (using a network-filesystem or ssh...)
> 
> I don't see why this would be done outside the server.  It's already
> easy to transfer big blocks of data in CORBA; just make a
> sequence<octet> (which is basically the CORBA version of unsigned
> char[]), and pass it in a call.  We've talked about bypassing CORBA in
> various ways in the past, but it doesn't seem to be worth it; the
> sequence<octet> passing code in most ORBs is highly optimized, and
> setting up those external transfer methods would be a huge pain.
ok... i understand... bypassing is not a good idea...
but i think... its not a bad idea to provide a set of std-objects that can
handle thinks on the client side with corba as the interface... thinks like
file-selector-boxes ect... ok.. may this not belongs to fresco... it's more 
like a external desktop-enviroment.

> > you can also use it like an xdm... or providing interfaces to the application
> > to store local configuration data...
> 
> I think these are separate problems, though interesting ones.  I think
> there is discussion of configuration stuff on the Wiki?
jup... i think so...

> 
> > [...]
> > i'll be happy for a response... i realy want to better understand fresco
> > 
> > sorry for my bad english... -_-
> 
> No problem; most of us developers aren't native speakers either :-).
> (I am, but I'm in the minority...)
thx again ^^;;

> -- Nathaniel
> 
> -- 
> Details are all that matters; God dwells there, and you never get to
> see Him if you don't struggle to get them right. -- Stephen Jay Gould
> 
> _______________________________________________
> Fresco-devel mailing list
> [email protected]
> http://lists.fresco.org/cgi-bin/listinfo/fresco-devel
> 

cinap