My feelings are about the same as Marcel's on all counts.
I don't mind extending the filter syntax for the simple case, but making
it much more complex doesn't seem to be that worthwhile, when those
cases will be seldom used. In those cases, just write some extra Java
code that does your filtering.
-> richard
Marcel Offermans wrote:
> 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
>
_______________________________________________
OSGi Developer Mail List
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev
