brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject Re: Resolving DSL
Date Fri, 23 Oct 2015 11:06:07 GMT

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 <martin.harris@cloudsoftcorp.com> 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.

Mime
View raw message