[Bf-funboard] Sky Generator

[Nathan Allworth]

Has anyone mentioned "webdav"? This is what Adobe uses for the base
behind it's Version Cue collaberation software which records comments
within and without files and versions as well as marking up entire
projects with todo lists etc. It's simple but it works great.

http://www.adobe.com/products/creativesuite/versioncue.html


On Mon, 08 Nov 2004 12:17:20 -0500, Robert Wenzlaff
<rwenzlaff at soylent-green.com> wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-funboard
> 


-- 
Nathan