Re: [tcf-dev] Basic wildcard for context query comparators

[Eugene Tarassov <eugene.tarassov@xxxxxxxxxx>]

> Would changing the syntax and allowing for single quoted string also be considered as breaking backward compatibility?

 

No, it would not. It is backward compatible, because existing clients are not supposed to use single quoted strings – it is prohibited by the syntax specs, so the change should not break them.

 

Regards,

Eugene

 

 

From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Coutand, Manuel
Sent: Friday, October 26, 2012 2:42 AM
To: TCF Development
Subject: Re: [tcf-dev] Basic wildcard for context query comparators

 

Using glob does seem better than my solution :).

 

Eugene, you say that support of glob syntax inside the quoted string would break backward compatibility. I agree.

 

Would changing the syntax and allowing for single quoted string also be considered as breaking backward compatibility? or is it ok since a client trying to use single quoted string in an "old" agent will get an error message and not crash.

 

If it is breaking backward compatibility, I suppose the solution is to write a new version of the service because adding a getCapability command to be able to probe that would also break backward compatibility. Am I correct?

 

Regards,

Manuel.

 

---

From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Eugene Tarassov
Sent: Thursday, October 25, 2012 11:12 PM
To: TCF Development
Subject: Re: [tcf-dev] Basic wildcard for context query comparators

I agree, supporting glob patterns makes a lot of sense. And it is easy to implement even if glob() function is not available. We cannot allow glob patterns inside a quoted string – it would break backward compatibility, but we can allow to use a different quote character for glob patterns (e.g. single quote).

Regards,

Eugene

 

From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Didier Brachet
Sent: Thursday, October 25, 2012 5:26 AM
To: tcf-dev@xxxxxxxxxxx
Subject: Re: [tcf-dev] Basic wildcard for context query comparators

 

Hello,

I agree using wildcard would greatly help in some situations. However, I will use a slightly different (and simpler IMO) syntax for the second case. The first query would be '/board/cpu*' but the second one would be '/board/"cpu[*"' instead of '/board/"cpu["* which seems more natural to me. Note that this implies that the character '*' will now also have to be escaped in the "quoted strings" (currently only characters '"' and '\' have to be escaped).

In the ideal, I think we should use the glob() function to implement this (simpler syntax than regexp) - I don't know if it is available on most OSes but if it is not we can certainly have our own implementation-. The good thing is that the syntax proposed by Manuel fit with the glob() syntax and will not introduce backward compatibility issues.

Eugene, if you agree with this we can work on an implementation and make a proposal.

Didier

Coutand, Manuel wrote:

Hi,

 

It would be usefull to have a basic wildcard/regexp capability in the context query name and id comparators.

 

for example if I have a system with these three contexts:

 

/board/cpu[0]

/board/cpu[1]

/board/memory

 

I would like to be able to get my CPUs using a context query.

 

This could be achieved without adding the full regexp syntax just by for example handling a * at the end of a string as a wildcard

 

for example: contextquery: '/board/cpu*' would match both CPU contexts

also the context query parsing could be done so: contextquery: '/board/"cpu["*' too would match both CPU contexts.

 

What are your thoughts on such a wildcard?

 

Regards,

Manuel.

 

 

_______________________________________________

tcf-dev mailing list

tcf-dev@xxxxxxxxxxx

http://dev.eclipse.org/mailman/listinfo/tcf-dev

 

-- 

Didier Brachet, Principal Technologist, Wind River

direct (33) 297.427.286 fax (33) 297.424.550

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.