Re: pengines extension to html_requires

On 02/08/2014 03:33 PM, Anne Ogborn wrote:
> 
> 
> 
>> It that true?  Why would you want to embed a Prolog script, just to
>> have the pengine it sending back to you?  The text/x-prolog fragments
>> just provide a space for real predicates to avoid over complicated
>> expressions in ask. 
> 
> I see your point, but keeping the code specific to a page with the page is an advantage.
> What prompted the question was generating a page that had some x-prolog fragments
> but needed to be dynamically generated for other portions of the page.

That modularity is exactly what the suggestions I gave achieve,
but without making the code round-trip to the client.  See below.

>> You can just as easily provide these in Prolog
>> itself and make them available to the module pengine_sandbox.  The
>> current way to do so is to write a module exporting this infrastructure
>> and using :- use_module(pengine_sandbox:my_api_file).
> 
> I"m afraid I'm not getting this pengine_sandbox module. I'm a bit baffled how
> one can qualify a module name like this?

Yes.  use_module/1 is a meta-predicate.  The module qualification decides
into which module the predicates exported from the module are imported.
The module  pengine_sandbox is the playground for all pengines.  This may
look a bit weird (it did for me at first glance), but works safely by
compiling all pengine-submitted code as thread_local (see thread_local/1).
That was a quite need trick by Torbjörn as it guarantees isolation and
cleanup without any further involvement.

>> That might not be ideal from a modularity point of view.  The other
> way is to write in some module 'xx' of your server:
> 
> :- public my_api/2.
> 
> my_api(A, B) :- ...
> 
>     ...
>     {|javascript||
>         ...
>         <calling xx:my_api(X,Y)> <-- =8cO hey, thats javascript!
>      |}
>     
> The nice architecture probably combines this: make generally useful
> APIs accessible using a module imported into the sandbox and use the
> above for page specific code.
> 
>> Does that make sense?
> 
> Sorry, not making sense of this example

You

  1. Define the utility predicate in the Prolog file where you'd
     like to call it from a generated JavaScript fragment.
  2. Declare it `public'.  safe_goal/1 considers all goals to
     module-private predicates as unsafe.
  3. Call the utility predicate explicitly in this module when
     you do the pengine `ask' operation.

Does that make sense?

> For example, we could consider adding a directive like this to replace
> the simple public directive:
> 
> :- pengine_api
>     my_api_1(<types/modes>) [is safe],
>     ...
> 
> which could wrap the predicate with type/mode checking to improve the
> security.   It would also make it easy to locate the pengine API in
> an application.
>     
> That feels more meta-analysis friendly.
> It's also probably a good move for security. Anything that puts in big bold letters ANYBODY ON THE NET CAN CALL THIS is a good idea.

Yes!

	Cheers --- Jan

> 
> Years ago I fiddled around with this same idea of code as query in Clojure. I made use of Clojure's meta syntax to mark public api's. Since keywords start with : in Clojure that gave scope to my smiley obsession - :oD  was the public API marker.
>