Hi Alex, Makes sense. I'm currently working on the "naive" path, but I can't find a way to resolve the $brooklyn DSL. Is there a sensible way of doing this?
Cheers M On 23 October 2015 at 12:06, Alex Heneveld <[email protected]> wrote: > > I don't think we can use TOSCA functions for Martin's example, at least > not directly. > > TOSCA functions have a much narrower scope, from what I understand, so it > is worth looking closely at that, and at the semantics around when the > functions are evaluate which I think in general is as early as possible. > Brooklyn OTOH evaluates them as late as possible. I don't know if the > Brooklyn way of putting promises (Tasks and Futures and DeferredSuppliers) > into maps to achieve this is compatible. > > I think the TOSCA way to handle Martin's use case is with requirements; > these could be translated into $brooklyn:attributeWhenReady when converting > to Brooklyn. However if converting from Brooklyn to TOSCA I expect we'll > need two paths: > > * a "naive" path which permits arbitrary strings set in TOSCA to be > evaluated by Brooklyn as YAML (and the $brooklyn DSL interpreted then) > * a requirements path which defines relevant requirements/relationships in > a generic way > > The second is likely quite a lot more work, and may require work for each > of many many different contexts where we use the Brooklyn DSL, but it will > lead to an elegant formal model around requirements and dependency > injection, as opposed to the semantically loose way the DSL is used. For > instance it would be very hard to support our current dependency injection > with an intuitive UI; the TOSCA formal model would give this, but of course > we'll have to do all the work to have types so that a UI can support the > many kinds of dependency injection that people do. Martin's use case is a > good first example. > > Best > Alex > > > > On 23/10/2015 11:15, Jose Carrasco wrote: > >> Hi all >> >> I think we should add support for TOSCA functions instead of use DSL >> directly on TOSCA templates. >> However, we could use the DSL implementations for supporting the TOSCA >> functions. For example, the concat function could be >> done using FormatString DSL class. And adding the FunctionWithArgs to the >> EntitySpec. >> The getAttribute function, {getAttribute template, att }, could be >> supported using getAttibute DSL, (of course using the tosca.node.type >> ConfigKey instead of camp.id) >> I am using these functions on Relations Section from TOSCA document (I >> will try finalize this section today ;-) ). >> >> does it make sense? >> >> Best, >> Jose >> >> >> El 23/10/2015, a las 11:57, Martin Harris < >> [email protected]> escribió: >> >> Hi Folks, >>> >>> As part of the TOSCA integration, we're (as an initial spike) passing >>> arbitrary DSL in as part of the TOSCA spec >>> >>> What is the best way to resolve the DSL, e.g. >>> `$brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s", >>> component("MySqlNode").attributeWhenReady("datastore.url"), "visitors", >>> "brooklyn", "br00k11n")` >>> >>> Cheers >>> >>> -- >>> Martin Harris >>> Lead Software Engineer >>> Cloudsoft Corporation Ltd >>> www.cloudsoftcorp.com >>> >>> -- >>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. >>> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP >>> >>> This e-mail message is confidential and for use by the addressee only. If >>> the message is received by anyone other than the addressee, please return >>> the message to the sender by replying to it and then delete the message >>> from your computer. Internet e-mails are not necessarily secure. >>> Cloudsoft >>> Corporation Limited does not accept responsibility for changes made to >>> this >>> message after it was sent. >>> >>> Whilst all reasonable care has been taken to avoid the transmission of >>> viruses, it is the responsibility of the recipient to ensure that the >>> onward transmission, opening or use of this message and any attachments >>> will not adversely affect its systems or data. No responsibility is >>> accepted by Cloudsoft Corporation Limited in this regard and the >>> recipient >>> should carry out such virus and other checks as it considers appropriate. >>> >> >> > > -- > Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. > Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP > > This e-mail message is confidential and for use by the addressee only. If > the message is received by anyone other than the addressee, please return > the message to the sender by replying to it and then delete the message > from your computer. Internet e-mails are not necessarily secure. Cloudsoft > Corporation Limited does not accept responsibility for changes made to this > message after it was sent. > > Whilst all reasonable care has been taken to avoid the transmission of > viruses, it is the responsibility of the recipient to ensure that the > onward transmission, opening or use of this message and any attachments > will not adversely affect its systems or data. No responsibility is > accepted by Cloudsoft Corporation Limited in this regard and the recipient > should carry out such virus and other checks as it considers appropriate. > -- Martin Harris Lead Software Engineer Cloudsoft Corporation Ltd www.cloudsoftcorp.com Mobile: +44 (0)7989 047-855 -- Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. Cloudsoft Corporation Limited does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by Cloudsoft Corporation Limited in this regard and the recipient should carry out such virus and other checks as it considers appropriate.
