Hi Robert,
2014-09-30 17:22 GMT+02:00 Robert Munteanu <[email protected]>: > I haven't looked very much in depth at this, but I like where this is > heading. A couple of questions/nitpicks: > > 1. Attaching additional information to artifacts currently looks like this > > org.apache.commons/commons-math/2.2/jar {sha1=2353750701ABE} > > How will multiple attributes look like? We can have a CSV list, e.g. > {att1=val1,att2=val2} or multiple space-separated groups, e.g. > {att1=val1} {att2=val2} . I think the first one looks better but needs > to define escaping. > Also, when I see a '{' '}' block I immediately think of code. Perhaps > it would be more intuitive to have these attributes enclosed in > parenthesis, e.g. '(sha1=CAFEBABE)'. > > While writing the parser I noticed that { } is not the best option anyway, as we also use this for variables ${var} So I changed to '[', ']' and multiple attributes would be [att1=val1,att2=val2]. Whitespaces within the block are ignored. Right now, no escaping is supported and simply assumed that neither the attribute name nor the value contain a "=" :) But that would be easy to fix. 2. One of the example OSGi configs has a string value quoted and also > escaped > > # A plain configuration > org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService > name="Default\ NodeStore" > repository.home="sling/oak/repository" > > Would it not be simpler to have the value be "Default NodeStore" ? > > This is how the Apache Felix CA Implementation writes the stuff out. I think that's a bug in the implementation and a space should not be escaped. However, you can write: name="Default NodeStore" and this is correctly read. But once config admin writes the configuration out, the space is escaped. > 3. Runmode configuration needs an additional section, and is ( I think > ) the only case where we have nested sections. Would it simplify the > model and make the file easier to understand by including them as > attributes to various sections ? I think this model looks somewhat > flat - which is a good thing - but is not very good at expressing deep > nesting like XML/JSON. > > [artifacts startLevel=15 runModeName=jackrabbit] > org.apache.derby/derby/10.5.3.0_1/jar > > org.apache.sling/org.apache.sling.jcr.jackrabbit.server/2.1.3-SNAPSHOT/jar > > > Yes, this is the area where I'm not 100% sure either. We have a nested model: feature -> run modes -> artifact groups (aka start level). If you're not using run modes nor start levels, then it's nicely flat and looks good. As soon as you're using one of it or even in combination it gets worse (this is where all tree based approaches shine). We could do what you're suggesting, but that requires repeating the same stuff over and over, e.g if you have two start levels for a runmode, you have to specify the run mode name twice etc. Carsten > Thanks, > > Robert > > > > > Regards > > Carsten > > > > 2014-09-30 8:11 GMT+02:00 Carsten Ziegeler <[email protected]>: > > > >> Hi, > >> > >> 2014-09-29 15:36 GMT+02:00 Carsten Ziegeler <[email protected]>: > >> > >>> Hi Bertrand, > >>> > >>> > >>> 2014-09-29 14:42 GMT+02:00 Bertrand Delacretaz <[email protected] > >: > >>> > >>>> > >>>> Can we call this "startup model" BTW? It's more descriptive than > >>>> slingstart. > >>>> > >>>> I'm fine with nearly any name, I just picked the first thing running > >>> through my brain... > >>> While "startup model" is more descriptive, the model can also be used > to > >>> describe partial systems (being it a subsystem etc.), therefore > "startup" > >>> is slightly missleading. > >>> The same goes with "instance model". I thought about "runtime model" > but > >>> that seems to be not 100% correct, either :) > >>> > >> > >> What about Sling Provisioning Model (SPM) ? > >> > >> Carsten > >> > >> > >> -- > >> Carsten Ziegeler > >> Adobe Research Switzerland > >> [email protected] > >> > > > > > > > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > [email protected] > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
