#foswiki 2017-02-06,Mon

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***ChanServ sets mode: +o gac410 [01:51]
.................................................................. (idle for 5h25mn)
ChanServ sets mode: +o cdot [07:16]
..... (idle for 20mn)
ChanServ sets mode: +o MichaelDaum [07:36]
................................................................ (idle for 5h19mn)
ChanServ sets mode: +o gac410 [12:55]
gac410Hi all ... Release meeting in 5 minutes [12:55]
cdot: Release meeting? Everyone else ... Release Meeting - Channel #foswiki-release [13:02]
....... (idle for 32mn)
GithubBot[distro] MichaelDaum pushed 1 new commit to Release02x01: https://git.io/vDWlh
distro/Release02x01 64f0024 MichaelDaum: Item14317: fixed packaging; removed bogus plugin
[13:34]
***GithubBot has left [13:34]
FoswikiBothttps://foswiki.org/Tasks/Item14317 [ Item14317: Under some conditions, JEditableContrib attempts to load an =.uncompressed.js= source, which is not in the distribution. ] [13:34]
GithubBot[distro] MichaelDaum pushed 1 new commit to master: https://git.io/vDW8f
distro/master cdd679e MichaelDaum: Merge branch 'Release02x01'
[13:34]
***GithubBot has left
ChanServ sets mode: +o Lynnwood
[13:34]
GithubBot[distro] MichaelDaum pushed 1 new commit to Item14288: https://git.io/vDW8g
distro/Item14288 da32e42 MichaelDaum: Merge branch 'master' into Item14288
[13:38]
***GithubBot has left [13:38]
FoswikiBothttps://foswiki.org/Tasks/Item14288 [ Item14288: rewrite to support pluggable edit engines ] [13:38]
.............. (idle for 1h6mn)
vrurgcdot: Wasn't it you who wrote the Configure? [14:44]
gac410configure evolved over time, and in the 2.0 incarnation, cdot rescued it from a rather disaster of a rewrite. Not sure who was the original author even if one could be identifed [14:47]
..................... (idle for 1h43mn)
***OliverKrueger has left "WeeChat 1.7" [16:30]
............ (idle for 57mn)
vrurggac410: Got back for a minute... Ok, that's gonna be another big issue then. I'm trying to keep the new specs similar in nature to the current code in order to preserve Configure's UI untouched. But it would still require serious rewriting to move from the old data structures. Sounds no good as not sure if anybody would take this task. :( [17:27]
gac410I don't really understand that vrurg [17:29]
vrurgIn few words: my new specs code would be useless without UI. UI code has to be rewritten. [17:31]
gac410oh ugh. [17:31]
vrurgAnd this is a task I would manage to do.
wouldn't
[17:31]
gac410Completely rewriting the UI and javascript would be well beyond anything I could even approach [17:32]
vrurgIt's not complete rewrite. I have a hope that javascript would remain untouched. But the Perl backend related to fetching and preparing specs data must be adapted to the new data structures.
And it's still a big thing to do.
[17:33]
gac410The big sales job is what motivates the spec rewrite. Is there some big gain that justifies so much reworking of configure. To me configure is as much a necessary evil - totally essential, but seldom used. [17:35]
vrurgIt's a big discussion I have no time for. Briefly, it's primarly for new plugins (extensions) support. With plugins it must be possible to have specs being written in different formats (namely – YAML, as was requested few times in proposals), different configuration backends (say, distributed storages like databases or whatever else could come to mind). Last but not least – clean separation of UI and data in core. [17:40]
gac410Do you have an example of the "new spec" for a plugin that shows what it looks like? [17:42]
vrurgSpecs itself are described in the proposal. New extensions are designed in a way that they can extend or even completely replace any core functionality. So, it will be possible to write an extension which will replace config read/write, for example. But to make it possible read and write must be well encapsulated methods of Foswiki::Config class. [17:46]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Config [17:46]
vrurgThis is very-very brief. [17:46]
gac410y. Unfortunately you are so deep in the new design, it's really hard to get a grasp of the concepts.
hey cdot ... do you have time to look at this?
[17:47]
cdotNo. [17:49]
gac410okay ;) [17:49]
vrurgThis is another nightmare in front of me: to have it all summarized in a single paper. With my English it's really hard to make it simple. [17:49]
cdotSeparating data and view is not a big deal, it could be done quite easily. [17:49]
vrurgBut the point is not only in separation but in getting rid of current specs format and making it pure perl data. [17:50]
cdotright now, the conflation of the two is only because of the desire to keep the LocalSite.cfg
which is pure perl data
the annotated perl data - the Config.spec - could easily be broken apart
[17:50]
vrurgSpecs are a language on its own forcing developers to learn it. [17:50]
cdotindeed. Whether you capture that as data or code, it still has to be learned. [17:51]
vrurghttps://foswiki.org/Development/OOConfigSpecsFormat [17:51]
cdotcdot has read many, many specs systems, and they all fall down on some point or other. [17:51]
gac410I think if I understand, An extension could create a yaml extension definition which "compiles" into the Foswik spec definition. [17:51]
cdotIf you wanted to, you could load the specs from YAML, edit them using a YAML editor. All you'd be losing is the documentation. [17:52]
vrurggac410: Correct. [17:52]
cdotgac410: No. That compilation would be "lossy". A .spec has far more information than a YAML spec would have.
Unless, of course, your YAML spec was HUGE!
(oit would have to spec all the stuff we use the annotation comments for)
[17:53]
vrurgcdot: This is the point: move the stuff in comments into the data structure describing a config key. [17:54]
cdotyou could do that, yes.
you'd still need a degree in writing config specs to get the YAML right, though.
[17:55]
gac410I suppose in some ways it simplifies configure in that the parsing of all the spec stuff gets done when "Build" generates the spec data structure from whatever source. [17:55]
vrurgcdot: Look at the proposal. [17:55]
gac410Which could continue to be the old style spec files I suppose. [17:55]
vrurggac410: Possible. I already have a parser for the old style, named it 'legacy'. [17:56]
gac410A compile step like that during "build" would also make configure a bit less vulnerable to typos in spec files, which today make configure "pink screen" [17:56]
cdotvrurg: I don't have a problem with what you want to do, I just don't see the point.
you would be replacing a somewhat flakey Config.spec parser with a more robust and checkable YAML parser, it is true
but I'm not aware that that is a big problem.
Of course if you want to extend the capability of the configure UI, then extending the YAML might be easier than extending the .spoc parser
but it's a bit marginal, IMHO.
[17:57]
vrurgcdot: No, read the proposal. I replace the old specs with Perl data format which is definitely much more clear to a developer. Plus few more reasons I defined above. [18:00]
cdotI did read it. [18:00]
vrurgYAML is a side effect possible. People want it – they can write it. Not me.
My initial point was making future clusterization possible.
[18:00]
cdotas I said, I don't have a problem with what you want to do. I just don't think it buys you much. [18:01]
vrurgA thing would be required for this is a distributed config. [18:01]
cdotYou still have to "know" how to write a config.spec
yes, it would open up some other possibilities, I grant you
[18:01]
vrurgSo, it all started with the point that config reading/writing is unclear and buried deeply in Configure code.
And then you know, one thing after another – it came to this point. :)
[18:02]
cdotunclear in what respect? https://foswiki.org/System/DevelopingPlugins
as long as you avoid the gribbly bits - DISPLAY_IF and ENABLE_IF mainly - it's pretty simple
sure, you could capture the syntax a different way, and that might help some other stuff - if it DOES help, go ahead.
[18:03]
gac410Y, even more convoluted are the also and check_also ... I still get that confused, so I put in both :P [18:05]
cdotgac410: sure, it's horrid - but moving into a DS won't help that, unfortunately. [18:05]
vrurgDS - what is it? [18:06]
gac410I think vrurg is at a point where he needs someone who is willing to look at the configure internals and change it from being the spec parser, to working off of a defined structure. [18:06]
cdotinternal in the code, the view and data models are well separated, so it's not that big a deal, as I said.
DS == Data Structure
[18:06]
vrurgBTW, while writing the legacy parser I found few undocumented features of the old specs. [18:06]
cdotit *does* work off a defined structure, internally.
vrurg: y, I'm not surprised.
[18:07]
gac410right, I do agree with that cdot - complicated concepts remain complicated concepts. config item co/inter dependency will probably always be comlex. [18:07]
cdotI did try to capture as much of the spec as possible, but a lot of it evolved without my input, so I had to reverse engineer parts of the doc. [18:08]
gac410gac410 created https://foswiki.org/Development/ImplementAdditiveTopicACLs ... shamelessly copied from t* Just ran across a site today that could really use that feature.
cdot, y, Timothe's extensions to configure were hellishly complicated in places.
[18:08]
vrurgOk, I have a lot of work. Whatever happens – I'm gonna finish it now. It's more than half way down to the target anyway. [18:09]
gac410;) [18:09]
vrurgcu later! [18:09]
gac410cu vrurg ... thanks for stopping by [18:09]
cdotOK, sure. I'll be interested to see it. It would be nice to simplify .spec's for sure. [18:10]
vrurgI miss it being here. Wathcing sometimes but no time for chatting. :( [18:10]
cdotvrurg: :-( [18:10]
gac410for some strange reason, employers want their employees undivided attention :D [18:11]
................. (idle for 1h22mn)
***ChanServ sets mode: +o Lynnwood [19:33]
...... (idle for 29mn)
ChanServ sets mode: +o Lynnwood
ChanServ sets mode: +o Lynnwood
[20:02]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)