Sounds great! I have to admit that as I was reading
the proposal I was thinking that there should be a
generic way to add new operators, but I agree with you
that it would cause too many problems. The filter is
one of these core things that should not have any
outside dependencies or behave differently depending
on the bundles installed.
ben
--- Peter Kriens <[EMAIL PROTECTED]> 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
>
> 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.
>
> 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.
>
> Kind regards,
>
> Peter Kriens
>
> --
> Peter Kriens Tel
> +33467542167
> 9C, Avenue St. Drézéry AOL,Yahoo:
> pkriens
> 34160 Beaulieu, France ICQ
> 255570717
> Skype pkriens Fax +1
> 8153772599
>
>
>
> You are currently subscribed to cpeg as:
> [EMAIL PROTECTED] If you would like to be
> removed from
> this list, please copy this phrase: "OSGi:
> unsubscribe cpeg [EMAIL PROTECTED] " to the
> subject line
> of an e-mail and send to [EMAIL PROTECTED]
> ---
> All email submissions and replies to OSGi Alliance
> email addresses are subject to the terms and
> conditions of the OSGi Alliance membership
> agreement.
>
> _______________________________________________
> 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
