Hi Alex, I've done a first pass on the document, and it's very impressive. Adding a procedural "sub-language" like this to Brooklyn could give it a whole new level of capability, which is very exciting. I have some thoughts on some of the details proposed which I will try to write up this week.
I share the concerns about YAML which I think Peter expressed very well. His suggestion of a DSL instead of YAML is interesting and I think would be worth considering. I also have some reservations about some of the constructs you're proposing (well, at least one of them) and some perhaps relatively minor suggestions for changes in structure. My bigger concern is that adding a new programming language within Blueprints like this could add a whole new dimension of complexity. I'm asking myself, "how would I debug this" when things go wrong. I think that's worth some discussion as much as the details of the language. There are also points where I simply have questions and would like some more detail. I'll try to get more detailed thoughts written up this week. Cheers Geoff On Sat, 27 Aug 2022 at 00:05, Peter Abramowitsch <pabramowit...@gmail.com> wrote: > Hi Alex, > I haven't been involved with the Brooklyn team for a long while so take > this suggestion with as little or as much importance as you see at face > value. Your proposal for a richer specification language to guide > realtime behavior is much appreciated and I think it is a great idea. > You've obviously thought very deeply as to how it could be applied in > different areas of a blueprint. > > My one comment is whether going for a declarative solution, especially one > based on YAML is optimal. Sure Yaml is well known, easy to eyeball, but it > has two drawbacks that make me wonder if it is the best platform for your > idea. The first is that it is a format-based language. Working in large > infrastructure projects, small errors can have disastrous consequences, so > as little as a missing or extra tab could result in destroying a data > resource or bringing down a complex system. The other, more philosophical > comment has to do with the clumsiness of describing procedural concepts in > a declarative language. (anyone have fun with XSL doing anything > significant?) > > So my suggestion would be to look into DSLs instead of Yaml. Very nice > ones can be created with little effort in Ruby Python, JS - and even Java. > In addition to having the language's own interpreter check the syntax for > you, you get lots of freebies such as being able to do line by line > debugging - and of course the obvious advantage that there is no code layer > between the DSL and its implementation, whereas with Yaml, someone needs to > write the code that converts the grammar into behavior, catch errors etc. > > What do you think? > > Peter > > On Wed, Aug 24, 2022 at 8:44 AM Alex Heneveld <a...@cloudsoft.io> wrote: > > > Hi folks, > > > > I'd like Apache Brooklyn to allow more sophisticated workflow to be > written > > in YAML. > > > > As many of you know, we have a powerful task framework in java, but only > a > > very limited subset is currently exposed via YAML. I think we could > > generalize this without a mammoth effort, and get a very nice way for > users > > to write complex effectors, sensor feeds, etc, directly in YAML. > > > > At [1] please find details of the proposal. > > > > This includes the ability to branch and retry on error. It can also give > > us the ability to retry/resume on an Apache Brooklyn server failover. > > > > Comments welcome! > > > > Best > > Alex > > > > > > [1] > > > > > https://docs.google.com/document/d/1u02Bi6sS8Fkf1s7UzRRMnvLhA477bqcyxGa0nJesqkI/edit?usp=sharing > > >
