Peter Kriens wrote:
> I am looking for some external feedback regarding the OSGi filter
> syntax. We are investigating if we should address some of the
> shortcomings in R5 or if this is not worth the required version
> change.
>
> The OSGi filter syntax is compatible with the LDAP filter syntax. This
> syntax has a few shortcomings that we inherited. For example, the
> syntax does not have operators for more (>) and less (<). There are
> work arounds for this because >= and <= as well as not (!) are
> supported.
>
> (a>b) <=> (!(a<=b))
>
> Today there is very little reason to not add these operators to the
> filter, it is likely to safe newcomers a few hours. The change is
> backward compatible but not forward compatible. Newer bundles that
> will use the new syntax will not run on older frameworks.
>
> If we decide add the > and < operators, we could afford to add more
> operators. The filter is used in many different places and a more
> powerful syntax would have its value. This mail is trying to start a
> discussion what kind of operators could be added.
>
> != not equal
I don't see these additions as enough reason to change the
specification. As you said you can accomplish the same result with the
existing syntax.
I don't think there is an efficiency issue (a Filter implementation can
optimize the parsed expression). The easiness to construct a Filter
expression is not an issue either (e.g. a GUI tool for building
expressions).
I don't think this is an issue for newcomers either, as far as I can
remember, understanding the Filter functionality/limitations was the
easiest part when I was introduced to OSGi ;-)
What is the very little reason to not add these operators you had in
mind (apart loosing forward compatibility) ?
>
> Additionally, we should consider adding regular expressions. Regular
> expressions are extremely powerful and play a major role in most
> mainstream languages like perl and php. We could consider using the /
> operator for regular expressions:
>
> / regular expression (requires java.util.regex)
>
> Working on OBR, I found I needed set operators: subset and superset:
>
> *> super set ( key *> {1,2,3} : the value of key, an array or
> collection must contain at least 1,2,3
> <* subset ( key <* {1,2,3} : key (which is a Collection or array)
> must contain at most 1,2,3 )
>
> The exact syntax and escaping needs to be worked upon.
I see it the other way around. If you decide to extend Filter Syntax by
adding regular expressions and/or set operators, which indeed add more
power to the syntax, then you might as well add the <,>,!= operators
that are missing.
Isn't java.util.regex requirement going to extend the minimum execution
environment of OSGi ?
Does anyone know of any drop in solutions for adding support to JRE
versions < 1.4 ?
>
> During initial discussion on the CPEG call the idea was brought up to
> create an extension model for the filter. This would allow third
> parties to add operators. I am not fond of this idea because it makes
> the presence of operators very fuzzy, it is hard to get popular
> operators when the presence of the operator depends on other installed
> bundles.
I'm not of the idea that a framework would depend on other installed
bundles. OTOH I think that support for exotic Filters could be provided
at some extent by defining e.g.
BundleContext.addServiceListener(ServiceListener listener, Filter filter)
BundleContext.getServiceReferences( String clazz, Filter
filter )
where one can provide whatever Filter implementation.
>
> Kind regards,
>
> Peter Kriens
>
Best regards,
Nektarios
--
______________________________________________________________
Nektarios K. Papadopoulos
Senior Engineer
Software Engineering Group
inAccess Networks
95A Pentelis Avenue. Tel : +30-210-6837640
152 34 Halandri Athens Fax : +30-210-6899504
______________________________________________________________
_______________________________________________
OSGi Developer Mail List
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
