Re: [MEXT] Binary Filters and the nature of MIP Re: binary filters draft 0

[Michael Eriksson <michael.eriksson at ericsson.com>]

On Wed, May 13, 2009 at 09:51:18 -0400, George Tsirtsis wrote:
> You seem to think of MIP and even of Connectivity Managers as a high
> level applications that live at user level. This viewpoint alone
> pretty much defines your opinion. It is of course true that a lot of
> public and research-type implementations of such functions are at user
> level, possibly using high level programming languages.
> 
> In the real commercial world, however, things are much different. To
> put any of this in a real world wireless, highly integrated device
> (think of iPhones, BBerrys, other smart phones and even netbooks etc)
> Connectivity Managers and Mobile IP will be highly optimized, low
> level application in C or even in Assembly. MIPv4 has been integrated
> in phones  by Nextel as part of the Direct Connect system, and I have
> personally been involved in one assembly implementation of Mobile IP
> during my Flarion years, and am now involved with another such low
> level implementation in my current company.
> 
> I hope this helps you understand where I (and probably others) come
> from when they are interested in binary filter rules, and why I keep
> saying that it is fine to have text filters too if people really want
> them but they cannot possibly be the default format.

At last some reasonable arguments!

As I have written before, I could live with binary rules. I just want
people to understand that a text-based rule language does have its
advantages.

Some random thoughts:

- I think that we must lift ourselves from native and portable
  assembler (aka C). As I wrote previously, the Android phone (very
  much a commercial product) is already doing all its logic in Java,
  which is a good start.

  I can understand that there are cost reduced products, where things
  have to be done in C. On the other hand, I think that only advanced
  terminals will do flow mobility, and they will/should have the power
  to use better programming languages.

- I think that you are vastly overestimating the implementation cost
  of parsing a text rule format. Lex and yacc compiles a lexical
  scanner and a language grammar into C code, which can then be
  compiled and linked into the final program.

  My complete (nonoptimized) lex+yacc parser for the text format, as
  specified in draft-larsson, is a total of 268 non-empty lines of
  source code, which compile into a total of 10476 bytes of i386
  object code. Sure you have room for that in your target devices?


Regards,
Michael