[Bf-committers] Re: listener object

[Douglas Toltzman]

I have only one caveat to add to this discussion.  Adding a 
socket/network interface to Blender will result in at least one more 
thread of execution.  If it is designed to handle multiple requesters, 
it will add one thread per client, at least.  Since Blender isn't yet 
multi-threaded, there will be no way for the client threads to know the 
exact state of the data that is being read.  i.e. the data could be in 
a transient state because it is being manipulated by the main thread.

Douglas Toltzman, Oak Street Software, Inc.
voice: 910-526-5938
http://www.oakstreetsoftware.com/

On May 11, 2005, at 5:42 AM, Toni Alatalo wrote:

>> Ton Roosendaal wrote:
>>> I don't think an "Always scrptlink" is the way to go... we should 
>>> keep
>>> things fully event based in Blender's UI.
>
> but, as said in the posts that followed (by Martin & Campbell),
> that was not about the UI, but having an invisible daemon running in
> Blender, serving requests coming from outside (e.g. information about
> what material some object is using etc., if i understood correctly).
>
> i agree that the 'always' scriptlink feels strange, and liked Martin's
> idea of a 'onIncomingSockedData' scriptlink or something like that. as 
> far
> as i can see the only benefit of the 'always' one would be that no 
> socket
> handling would be needed on the C side of Blender, which would only 
> need
> to activate the scripts from the mainloop using some sort of timer
> perhaps. that is how it has always worked on the game engine side, 
> where
> there actually is an 'always' sensor, that has been used to implement
> network servers within Blender too - doing all the networking in Python
> only.
>
> first i thought that the 'always' scriptlink might be useful for other
> kind of background-processing python scripts too, but those probably 
> are
> better off as event-driven (perhaps with SceneChanged or something like
> that added if needed, but that's irrelevant to this discussion).
>
> did something come out of this already, what did Martin&co choose to 
> do?
> .. oh just noticed that he's posting follow-ups to bf-python, i'll be
> looking there and wont post more here anymore either.
>
>>> Would it be possible for Python to add callbacks instead? Meaning, it
>>> assigns to an external program the means to insert events in the main
>>> queue, which is then being handled by another script. Could also be a
>>> means to plugin input devices.
>
> i guess that is possible. and as Martin and others saw, sockets are an 
> ok
> way for it. just the mechanism to enable bpython scripts to receive 
> socket
> connections is needed, for example by making either the 'always' /
> 'onTimer' or 'onIncomingSocketData' scriptlinks. right?
>
>>> -Ton-
>
> ~Toni
>
>>> On 6 May, 2005, at 13:21, Martin DeMello wrote:
>>>
>>>> On 5/6/05, Martin DeMello <martindemello at gmail.com> wrote:
>>>>
>>>>> I'd like to add a "listener" object to blender, to allow a script 
>>>>> to
>>>>> be triggered by an external program writing to a socket. (Not
>>>>> necessarily proposing this be added to blender proper, but it 
>>>>> would be
>>>>> very useful for my own copy.) Is this an intrinsically dangerous 
>>>>> idea?
>>>>> (i.e. could it cause instability or crashes in blender?) If not, 
>>>>> how
>>>>> would I go about doing it? (i.e., where in the code should I be
>>>>> looking to add something like this?)
>>>> Also, antont suggested on IRC that an 'always' scriptlink that
>>>> activated once every timer tick would be another nice way to
>>>> accomplish this. The triggered python script could then poll the
>>>> socket.
>>>>
>>>> martin
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>