Requirements for the Backend library

[David Pineau]

Hey there !

A few of us had an interesting discussion about the back-end library
and the data it should contain.
In order to help define a tentative schema for the underlying DB (or
at least an API), I will write here what do we actually need. So
sorry if it's a bit lengthy, but I also want to explain why we need
each of these informations.

So, let's begin with our entities within the Rathaxes language and how
they relate to each other:

An interface (possibly an extension):
- Describes:
* Types:
- Describes:
* Mapping (Associations: identifier -> type)
* Chunks (Chunks related to pointcuts Or member functions
unrelated to any pointcut)
* Declaration (A specific chunk to be specified)
* Subtypes
- Depends on:
* His super-type if it's a subtype itself.
* Sequences:
- Describes:
* Prototype
* Chunks (including the builtin "::CALL()" sharing the
sequence's prototype for explicit calls)
* Pointcuts
- Depends on:
* Each type (and thus their interfaces) used within its prototype
* Callbacks:
- Describes:
* Prototype (to be used in the front-end)
* Chunks
* Pointcuts (including the builtin "::IMPLEMENTATION"
which is where the front-en algorithm may be inserted)
- Depends on:
* Each type (and thus their interfaces) used within its prototype
* Configuration parameters
- Describes:
* Name (identifier)
- Depends on:
* Own Type (from a Type template)
- Depends on:
* Interfaces (0 and more, not limited)
* Original interface (if it is an extension, but I don't think it
should have another extension as an original interface)

There it is for the description.
Obviously, every type of template (type, sequence, callback), as well
as the interface extensions are what I would call "implementations" of
their descriptions.

During the generation process, each template required for the weaving
should be selected through a configuration matching, and only one
implementation for each template should be used throughout the
generation process.

A configuration is a specification of the Configuration parameters
described by the interfaces. A template (or interface extension)
"with" block is a set of constraints over the Configuration parameter.
That is, it includes for each constraint: The name of the
Configuration parameter, a comparison operator, and a reference value
(to compare against the generation's configuration parameter). The
generation's configuration is a set of values associated to some
configuration parameters.

Now, for the more specific details about the implementations, we could
also say that each implementation depends on the templates (types or
sequences) that it explicitly uses within the instrumented C code.

So when we're looking for a template/chunk, what we need to do is:
- Select an implementation by configuration matching
- Recursively:
* Retrieve the dependencies
* Select an implementation by configuration matching for this dependency
- Make sure for all selected implementations, that their whole code
is weaved (we must not miss a chunk of code at the end)




Well, there you have something to feed your brains on , and I don't
think it's missing much.

--
David Pineau,
Developer R&D at Scality

[Thomas Sanchez]

Will read this weekend, thanks for the post though !

2013/11/21 David Pineau <dav.p...@gmail.com>:

> --
> --
> ML Rathaxes
> www.rathaxes.org
>
> ---
> You received this message because you are subscribed to the Google Groups "Rathaxes Development List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rathaxes-deve...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Thomas Sanchez

[Thomas Sanchez]

I was working on Rathaxes with your indications to create a schema,
however, I was wondering what is a "Callback", in what this is
different from a sequence ?
I lookup in the ML and the repo to see if I forgot/missed something
but I found nothing.

2013/11/22 Thomas Sanchez <thomas...@gmail.com>:

--
Thomas Sanchez

[Thomas Sanchez]

While I'm here:
A type's subtype is relevant when we want to expose a structure
composed of several RTX types ?
If yes shouldn't we have a specific primitive similar as the C structure ?

2013/11/24 Thomas Sanchez <thomas...@gmail.com>:

--
Thomas Sanchez

[David Pineau]

For the callbacks:
Up until now, we only had "sequences". Now, for the front-end, we
want to differentiate sequences (to be used by calling them), and
Callbacks (to be used by implementing them).
In the backend, the only difference is that of the required/provided
sequences: The callback will provide a builtin ::IMPLEMENTATION
pointcut for the front-end to insert its algorithm while a sequence
will provide a "::CALL" chunk to be able to call the sequence.

For the subtype, What do you mean ?
It was originally designed to resolve the issue of cross-layer
interference created by the need for each sub-system to provide its
own context, almost always embedded into the upper sub-system. We had
to break the isolation of the sub-systems from one another in order to
manage such type embedding. The subtypes aim to solve this issue, so
I'm not sure I'm understanding you on this one.

The secondary aim of the subtypes was an example given in the
brainstorming mail, to use for collections, and create a system
similar to a C++ template, although much more simple.

2013/11/24 Thomas Sanchez <thomas...@gmail.com>: