[Bf-committers] Thinking about a "community edit mode" for blender

[Chad Fraleigh]

Oh and one thing that would definitely have to be done for security is
locking out access to arbitrary file paths while in shared edit mode
(perhaps defining a drive and/or directory white-list ahead of time).
That way remote users couldn't manipulate your system via special
files/devices that have side affects from just opening them.

And I just remembered watching a macro tutorial recently, which
implies that a lot of what is needed do high level replication already
exists.

While on this subject it got me thinking of another feature (which may
or may not already exist somewhere).. If actions can be "replay"
replicated between multiple instances of blender, then why not to
itself? The Smalltalk IDE by VisualWorks has image files (a snapshot
of the VM) and a change list/log. Because of this if the VM crashes
(or hangs and you have to kill it off) not all is lost from the last
image save. You can simply replay the change file (or even select
parts of it) and get back to where you left off. So if something like
this existed in blender (or an addon) then when blender crashes (which
I get the impression happens often with the newer features before they
have a few releases to become stable) it would be trivial to recover.
Maybe even when opening a "crashed" file it would ask if you want to
replay the changes. There are other examples of this (like 'vi' and
other editors), but VisualWorks could also do more with change lists
than just recover that session (which is the general limit in text
editors). If done right it could be used to export a set of changes as
a diff/patch like mechanism for .blend files (unless that's not very
useful in practice). Anyway that's enough on these side tangents.


On Sun, Nov 18, 2012 at 3:07 PM, Chad Fraleigh <chadf at triularity.org> wrote:
> What about instead of trying to keep the internal data directly in
> sync it was treated more like a high level database replay log. Sync
> the operations, like select vertex #5, begin move action, move by x/y,
> end move action; or set modifier #1 field X to value Y. Assuming all
> instances started out with logically identical data/state and have the
> same capabilities (i.e. same blender version, and same [active]
> addons), then in the end each edited copy should be identical. Of
> course this also assumes that all "actions" (whether UI or script
> triggered) can be hooked/captured and replicated to the other node(s).
>
> One catch would be any local system specific data (like non-relative
> filenames) that might get applied would not be portable across nodes.
> If support for virtual/aliased/mapped file resources existed, then
> both sides could have their system dependent resources mapped, and
> then these virtual "filenames" could be passed back and forth. While
> not a complete solution, it would allow even those that have a
> collection of [non-common directory] external data on incompatible
> directory structures (or OS's) to still work together. For that matter
> there could even be exported virtual resources.. so if resource X
> wasn't mapped on one side it could pull the data remotely from another
> node that does have it (when allowed).

-Chad