Re: [Simca-developers] Re: corba

[Simon de B. <si...@z2...>]

> solution: add the list to your .muttrc and answer with 'L' instead of
> 'r' in mutt. i've just done that :)
It worked ! :)

> - open preview of a message while keeping list of messages partially
>   visible. 

you can set e.g. pager_index_lines=10 when viewing a message you can
move to the index tree. Not quite what you mean but I think as close as
you can get.

> 
> it's so frustrating to man muttrc over dialup line :)
can imagine...

> 
> > 
> > > > 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).
true,

> 
> 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.
> 

Isn't that what a (ffmpeg) stream in/out objects should take care of? Or will
connector be able to 'recognize' some standard streams.

-- 
Simon de Bakker

\/01|)7	workgroup: http://www.void7.org
personal homepage: http://www.josos.org