On Nov 2, 2006, at 11:59 , Peter Kriens wrote:
> I am looking for some external feedback regarding the OSGi filter
> syntax. [...]
> 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
+1
I agree with adding these, it makes sense to have them because it
makes the filter conditions more readable.
Regarding compatibility with previous releases, a utility class might
be supplied that could translate the new filter syntax to an R4
compatible one (to help developers create bundles that can still be
deployed in !(>=R5) environments).
> 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.
-1
On the other hand, regular expressions are a lot more difficult to
convert into SQL queries (something that is not too hard for LDAP
expressions). Personally I would rather not see them added to the
filter spec.
> 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.
0
I'm pretty neutral on these operators. Just out of curiosity, where
exactly in OBR would these be necessary?
> 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.
-1
I'm very much against this. Filters are used for a lot of core OSGi
stuff (in service trackers and even for matching native libraries).
If people start using extensions in these expressions, and those
extensions would be removed at runtime, then things would stop working.
I agree with Nektarios that you should simply create your own filter
code if you need more complex filters. But, to be honest, I've never
ever felt the need to do that yet.
Greetings, Marcel
_______________________________________________
OSGi Developer Mail List
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
