Re: [Simca-developers] Re: corba

[Artyom B. <ar...@z2...>]

On Wed, Mar 19, 2003 at 03:24:43PM +0100, Simon de Bakker wrote:
> On Wed, Mar 19, 2003 at 03:03:39PM +0100, Artyom Baguinski wrote:
> > you keep on answering outside the list aren't you?
> you got me; little mistake, pressed 'y' to fast... 
solution: add the list to your .muttrc and answer with 'L' instead of
'r' in mutt. i've just done that :)

and by the way, do you know how to make mutt:
- go to old unread mail when i press space / tab (now it only goes to
  new mail
- open preview of a message while keeping list of messages partially
  visible. 

it's so frustrating to man muttrc over dialup line :)

> 
> > > During the pipeline creation simca should find out whether the link is
> > > local or remote, maybe even what type of link objects support
> > > (udp,tcp,..) and ask for hints. Depending it can decide what way is best for this link.
> > > 
> > 
> > yes this sounds like interesting strategy. i was thinking to make it
> > more automagic - like every server has a number of connectors that would
> > listen to incoming data and server decides which connector to use for
> > every incoming remote link balancing the load of every connector. 
> > 
> > but hinting can help - actually at the connection establishing time
> > server knows nothing about the load - that's what one could hint. 
> 
> The hinting I introduced because different objects may favor different
> types of connections. So does a stream object need a reliable tcp
> connection and support for larger packet sizes than does e.g. a
> realtime sensor input. For the latter it might not be a problem if it
> loses some packages along the way if it is delivered as fast as
> possible. This is known by the object and can hint the connection
> mechanism. The object itself actually doesn't care how it is done, it
> might use tcp because the connection mechanism finds the other end needs it, but if needed it can demand. This means objects demanding different connection types cannot connect (unless used with a converter object ?).
> 

we should have "properties properties" (because it depends on a
connected properties what kind of connector to use, not on an object).

i was thinking, connectors can be even more complicated when they are
across the network: imagine we have ffmpeg streaming server available
and find it handier to stream media using it instead of sending via tcp
"manually". all the other side has to do is to capture the stream. the
same mechanizm will allow feed in external (not simca) media streams, as
long as ffmpeg client can deal with them.

(you should have guessed already - i've installed ffmpeg :)

cheers

-- 
Artem Baguinski: <ar...@v2...> <http://www.artm.org/>
V2_lab: <http://lab.v2.nl/> <http://www.v2.nl/>