[Bf-funboard] Sky Generator

[Robert Wenzlaff]

At 10:16 AM 11/8/04, you wrote:
>In a professional setup, your data is stored on a remote server anyway 
>(via NFS),
>namely your company's (or home's :) fileserver, and this server does 
>regular backups to a suitable backup system automatically
>without any user interaction.

And in a non-professional setup it's just going to be a 
directory.  Ideally, we want pros and non-pros to see the same thing.

For *ix's there is ftpfs which allows you to mount an FTP server as part of 
your file system.  Writes to that dir issue the appropriate 'put' command 
and reads the 'get'.  But that may not be the best way for remote 
collaboration since I don't know how/if it works over the Win based platforms.

I suppose that it wouldn't be that difficult to make Blender use sockets if 
the library directory to be read starts with "http://" (or whatever), but 
it opens a whole can of worms as to how the server-side must be set up.

Before we consider any work on this, we should all have a clear path to 
follow.  Any decisions made here now we are going to have to live with for 
quite some time.

This is probably one of the few weaknesses of Open Source programming.  A 
good-enough solution presents itself without any real planning for the 
future, and often a "good-enough" solution is the only thing that prevents 
an excellent solution from coming into existence (See just about any 
software by M$).

Of course, the best alternative to planning is the classic side-step.  How 
about this?  Since scripts can appear as menu items now, can we make remote 
access a script based function?  That way different server technologies can 
be implemented transparently (after setup) by publishing their own access 
scripts.  There would of course be common ground that can be shared, ie; a 
basic script that the sites use as-is if they follow "the official" method, 
or modify if they don't/can't (not all webservers have an SQL server turned 
on for free).

It adds one level to getting/saving remote info 
(Material->Library->Remote_server->Mat_Name, vs. 
Material->Library->Mat_Name), but doesn't lock blender in to any one 
method.  It probably should be obvious to the user that the info is coming 
in remotely anyway, so he doesn't go nuts wondering where his texture went 
when the network is down...

You can also use a mix of local/remote lib info pretty easily this way.  So 
the pros with an NFS or Samba server dedicated to such will never need to 
be bothered by this layer.

Each remote server can be a separate menu item (different scripts in the 
script dir) or one script can place different servers as a second step in 
the menu hierarchy.   The script_to_menu system handles all this pretty 
seamlessly (or should).

Robert Wenzlaff
AKA Detective Thorn