Dnia Wednesday 18 of June 2008, Gerrit Renker napisał: > | > In the kernel I think it is best to make it type-safe, i.e. no new > | > parameters to already-defined policies. But I can't see how this would > | > restrict the use. > | > (...) > | > | So we would need new policy for each new parameter, right? I somehow > | don't like it but it should work. You are right that this way runtime > | parameter discovery is not necessary. BTW, we will have a bit of a > | problem with naming qpolicies ;-) > > Yes, not claiming that my suggestions were very good. > > By the way, did you notice that the matrix was incomplete - timeout > standalone was missing, the corrected version would look something like > Well, I assumed that you did that on purpose because that would imply that we need more or less N policies for N parameters added one at a time. When we want separate policy for just timeout we end up with 2^N policies. And that would be just mad because the same effect can easily be achieved with setting priority to the same value on all packets. > +-------------+--------+-------------------+------------------+ > > | Policy Name | Policy | Presence of Parameters | > | > | | ID# | DCCP_SCM_PRIORITY | DCCP_SCM_TIMEOUT | > > +-------------+--------+-------------------+------------------+ > > | "simple | 0 | no | no | > | "prio" | 1 | YES | no | > | "timeout" | 2? | no | YES | > | "timed-prio"| 3? | YES | YES | > > +-------------+--------+-------------------+------------------+ > > There is a special trick for the aggregate "timed-prio" policy: it is > the logical-OR of the "prio" and "timeout" policy IDs. Perhaps composite > policy IDs could be defined in this way. > Then we would have straight mapping between possible parameters and policy numbers. That is, effectively we would not set the policy number but request the capability of processing certain parameters, right? So that the application could specify 0, DCCP_SCM_PRIORITY, DCCP_SCM_TIMEOUT or DCCP_SCM_PRIORITY|DCCP_SCM_TIMEOUT as the policy ID? Could be nice, but what happens if we have two policies with the same set of supported parameters? How do we differentiate them? In the above: how do we diffrentiate between simple policy (which doesn't have any parameters ever) and prio policy with no parameters (just because we don't need to provide any for one particular case)? > | I will for sure be working on some apps to demonstrate how the new > | interface can be used. But first I need to create a simple server/client > | transmitting G.726 encoded voice over UDP/RTP (any hints on that?)... > > Tommi Saviranta has been working on a DCCP port for SpeexComm: > http://tuomas.kulve.fi/projects/speexcomm/ > The port is available via SVN: > svn co http://tuomas.kulve.fi/svn/speexcomm > > Leandro Sales de Melo has developed a DCCP plugin for gstreamer and used > it with VoIP/speex. It comes with example applications for these: > https://garage.maemo.org/frs/?group_id=297 > https://garage.maemo.org/projects/ephone > http://www.mail-archive.com/dccp@xxxxxxxxxxxxxxx/msg03101.html > I'll have a look at these. It seems that GStreamer is the way to go. However, there is a minor glitch. GStreamer doesn't support a clean way of passing priority data between plugins, so the code will probably be a bit ugly. -- Regards, Tomasz Grobelny -- To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
