| Yet another question about touchpoint data.
Does it matter if an IU is authored so that there is only one instruction per TouchpointData? This would make it easier in the user interface. The user would then only see two levels - the instruction (install, uninstall, etc.), and the actions for the instruction. The grouping of several instructions seems to have no semantic meaning (but is useful at runtime).
Thus, the user can add install, uninstall, etc. instructions, and add actions to them but do not have to be concerned with grouping at all. Do you think this approach is ok?
Regards On 23 jun 2008, at 21.40, Simon Kaegi wrote: > Hm, I think may able to answer this myself. The format is actually
> documented :)
>
> The touchpoint data has a map, the keys in this map are the phases
> like "install", and the value is the format described on the wiki
> page - i.e. a string that needs to be parsed
> to understand the actions and parameters i.e "action1
> (paramname1:value, paramname2:value, paramname3:value);action2(...); ..."
>
> Can someone confirm - or have I got it wrong yet one more time :) ?
Yep. That's it. You've got it.
>
> Henrik Lindberg
> henrik.lindberg@xxxxxxxxxxxxxx
>
> On 23 jun 2008, at 17.25, Henrik Lindberg wrote:
>
> Thanks Simon,
> Hm, seems that my understanding of this is still unclear. I
> understand touchpoint type - one IU can affect one touchpoint only,
> but I have trouble with Touchpoint Data.
> The IU has a list of Touchpoint Data. What exactly is one such
> Touchpoint Data instance describing? I thought it was one
> instruction like "chmod", but now I am uncertain. From your response
> it seems like one Touchpoint Data instance describes a set of
> instructions for a phase like "install" - or is it even capable of
> describing multiple sets of instructions for different phases?
>
> Is the following correct touchpoint data?
>
> touchpoint data = a Map {
> { key = "install", value= a Map {
> {key=setXXX, value= aMap { {key=param1, value="" } {key=param2, value=""}},
> {key=chmod, value= aMap { {key=param1, value="" } {key=param2, value=""}} }
> { key = uninstall, value= a Map {
> // instructions for uninstall...
> } }
> }
>
> If that is true, then I will update the wiki page to make it clear -
> an "instruction" is the top level thing (i.e. "install",
> "uninstall"), and in such an instruction it is possible to specify
> actions (but only one action instance per type of action).
>
> Henrik Lindberg
> henrik.lindberg@xxxxxxxxxxxxxx
>
> On 23 jun 2008, at 16.27, Simon Kaegi wrote:
>
>
> > A couple of notes and questions:
> > - With the current encoding (a map of instructions), it is not
> > possible to use the same instruction type more than once. Is this
> > intentional? What if the author needs to create two directories etc?
> > (I am asking because if this will be changed in the future I want to
> > allow the user to add more than one of the same instruction type).
>
> At runtime the intent is to allow a "resolved" IU to provide
> multiple instructions with the same key. e.g. multiple "install"
> instructions is fair game.
> I use "runtime" and "resolved" because one of the important uses of
> multiple instructions is to allow IUFragments to provide additional
> instructions with the same key.
> e.g. an IU when resolved with IUFragments might provide multiple
> "install" instructions.
>
> At dev time I would suggest only using one instruction for each key
> although I don't believe there is a formal restriction here.
>
> > I think I may have understood the format wrong. Does an instance of
> > TouchpointData describe one instruction?
>
> Multiple instructions are fine... e.g. an IU's touchpoint data
> section can provide an "install", "uninstall", "configure", etc. set
> of instructions.
>
> > - Why the special use of "@artifact" instead of an injected
> > parameter like "artifactDir" that can be included with $
> > {artifactDir} ? (I am asking because I am thinking about what kind
> > of editing support to offer - perhaps browse/select from available
> > parameters, and the @artifact is different than the other parameters).
>
> Yes this is something we can cleanup. Originally we didn't have a
> place to initialize parameters that would get set by an action from
> an earlier phase.
> There are a few other changes that need to be done here also to
> allow referencing more than just the first artifact of an IU. As a
> result I was reluctant to do a change here late in the cycle.
>
> > - How are actions executed during the phases? (I have not studied
> > the code), but it seems logical that what is specified in the IU's
> > touchpoint data gets executed during install and uninstall - and
> > that the install phase executes the Action's "execute" the
> > uninstall executes the Action's "undo" - is this correct?
>
> Undo is used "only" when rolling back a failed set of operations.
> e.g. during the uninstall phase we use explicit uninstallbundle actions.
> The reason this is the case is that an action/undo pair is not
> always perfectly symmetric e.g. an action can be destructive (for
> example over-writing a program argument). In these cases the actions
> "undo" can restore from a saved memento.
>
> -Simon
>
> >
> > Henrik Lindberg
> > henrik.lindberg@xxxxxxxxxxxxxx
> >
> > On 20 jun 2008, at 04.56, Simon Kaegi wrote:
> >
> > > I have now written a wiki page: http://wiki.eclipse.org/
> > > Equinox_p2_Touchpoint_Instructions describing the touchpoint
> > > instructions for the native and eclipse touchpoints, their
> > > parameters, and how I think it works after reading the code. There
> > > are places where I need help (indicated by blue comment boxes), but
> > > I may have gotten other things wrong as well.
> > >
> > > It is probably of value to also describe the parameters inserted by
> > > the engine as these can be used in parameter substitution. I don't
> > > know if it is intended, but it seems very powerful to be able to
> > > reference the "previous value". Shall I just make a list of what I
> > > find, and include it?
> > >
> > > So, I hope someone has time to review and comment on the
> > > documentation on the wiki page.
> >
> > Great job.
> > I'll go through and review tomorrow.
> > While reading through I recognized there is some overlap with an
> > earlier page -- http://wiki.eclipse.org/Equinox_p2_Engine
> > Your presentation is vastly better and easier to understand so I'll
> > go through and do some merging/updating/re-organizing of that content.
> >
> > Thanks.
> > -Simon
> >
> > >
> > > Regards
> > >
> > > Henrik Lindberg
> > > henrik.lindberg@xxxxxxxxxxxxxx
> > >
> > > On 18 jun 2008, at 19.13, Simon Kaegi wrote:
> > >
> > > > - How can I learn what the input to the actions are? Some parameters
> > > > look like they are provided by the runtime (i.e. not specified in the
> > > > iu touchpoint data). If there is no documentation, I can write up a
> > > > list of what I think the parameter are and ask for someone to review.
> > >
> > > That would be incredibly appreciated.
> > > _______________________________________________
> > > equinox-dev mailing list
> > > equinox-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
|
