[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] p2 QL feedback / discussion
|
First off, the geek in me thinks that p2ql is pretty cool. It should open up a lot of interesting extensions to p2 (like the work that Tom W. was doing).
I do have two concerns though:
1. The learning curve. Even the most active p2 committers are likely only going to write a few p2ql queries a year. This means that each time you go to write a query, you'll likely have to re-learn the language.
2. Debugging / A language in a language. I'm not a fan of "A language in a language" mostly because there is no type / syntax support. Mix in the fact that there is no tooling (like debuggers), and things may get difficult.
I also have a question. How do we define API? What can and cannot change with respect to language? How do we ensure this?
cheers,
ian
On Fri, Feb 26, 2010 at 12:02 PM, Pascal Rapicault
<pascal@xxxxxxxxxxxx> wrote:
Personally I'm worried about the learning curve to new comers (and old comers as well :)) because I now have to learn a language to do something simple that I use to be able to do with a bit of code.
Therefore I was thinking that it may be interesting to add new helper queries to do things like:
- find an IU whose ID contains a string instead of being a full match.
- find an IU that has a set of capability
Also we need to have a bunch of little example explaining what they do in addition to a more descriptive guide of the syntax. Also being able to relate the language to something known (e.g. OCL) could help.
Now from a code maintainer point of view, this language is part of the API. So it brings 2 questions:
- how to we evolve it in a backward compatible way? not really an urgent matter but still.
- do we leak any implementation detail? Are we too close to the actual data structure. For example I see references to IInstallableUnitPatch.class or such. Can't we avoid this?
PaScaL
On 2010-02-26, at 11:32 AM, Thomas Watson wrote:
I have a concern about how closely the syntax is tied to the repository metadata syntax and the data structure of the IU. For example, how you search for the latest versions of all the UIs that provide the osgi.bundle capability goes something like this:
latest(x | x.providedCapabilities.exists(p | p.namespace == 'osgi.bundle'))
My understanding is that this will return all the latest versions of the IUs that provide the capability with the namespace of osgi.bundle. So there are a couple of concerns I can see if this QL is expected to work for all future releases of p2.
- IUs must always have a way to get the list of provided capabilities using the .providedCapabilities syntax. (probably pretty safe bet?)
- Capabilities must always have something called a namespace. Not sure if this is always going to be true. I guess even OBR will have resources (capabilities) that provide some kind of name space.
- The name space value becomes API. 'osgi.bundle' must always be the namespace to represent a bundle. AFAICT there is no place in the p2 API that lists the namespace values as API. The feel like they are an internal detail to me.
I also don't see any documentation on the various fields that can be used in a query (.providesCapabilities, .namespace etc.) and what their corresponding types are.
Tom
<graycol.gif>Pascal Rapicault ---02/26/2010 09:55:33 AM---With the latest changes that Thomas committed this week, we are now fully p2 QL enabled. Thank you.
<ecblank.gif>
From: | <ecblank.gif> |
<ecblank.gif>
To: | <ecblank.gif> |
<ecblank.gif>
Date: | <ecblank.gif>
02/26/2010 09:55 AM
|
<ecblank.gif>
Subject: | <ecblank.gif>
[p2-dev] p2 QL feedback / discussion
|
With the latest changes that Thomas committed this week, we are now fully p2 QL enabled. Thank you.
Overall this is a good step forward and bring to p2 a really neat point of flexibility. However before we wrap up on the API, I'm soliciting feedback on it. What do you think of it, what are your worries, are there any simple things we can do?
PaScaL_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com |
http://twitter.com/eclipsesource
