So what do people think? Should we rather go with
[runMode name=jackrabbit] [artifacts startLevel=1] ..artifacts for level 1 [artifacts startLevel=5] ..artifacts for level 5 [configurations] ..configurations [settings] .settings or [artifacts startLevel=1 runMode=jackrabbit] ..artifacts for level 1 [artifacts startLevel=5 runMode=jackrabbit] ..artifacts for level 5 [configurations runMode=jackrabbit] ..configurations [settings runMode=jackrabbit] .settings The latter is easier to read/understand but requires more typing. WDYT? Please note that this only affects the textual representation, the object model is still tree based. Carsten 2014-09-30 17:48 GMT+02:00 Carsten Ziegeler <[email protected]>: > 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] > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
