<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 05/19/2016 01:28 PM, Dick Muller
wrote:<br>
</div>
<blockquote
cite="mid:C5CB4143-C558-4096-BD3E-C54CA5ADB048@tahzoo.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Courier New";
panose-1:2 7 3 9 2 2 5 2 4 4;}
@font-face
{font-family:"Cambria Math";
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:Calibri;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Courier;}
span.EmailStyle19
{mso-style-type:personal;
font-family:Calibri;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
<div class="WordSection1"><span style="font-size:11.0pt">But why
is it so difficult.<o:p></o:p></span>
<p class="MsoNormal"><span style="font-size:11.0pt">For Outbound
I created a Metarole group and work with an association.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">You would
expect that inbound more or less works the same?</span></p>
</div>
</blockquote>
<br>
The idea of outbound and inbound mappings is the same. Most of the
lower-level code is shared (mapping evaluation, expression
evaluation). But the hight-level code for outbound and inbound is
slightly different. And there I expect some issues. There is special
handling for associations in the outbound part of the code (e.g. to
correctly reconcile them). Equivalent code is missing in the inbound
part. The code cannot be entirely the same, as the high-level logic
for handling inbound and outbound direction is almost reversed. For
outbound code the association is in fact expression output. But for
inbound it is the input. I have created special-purpose expressions
such as associationTargetSearch and associationFromLink that are
easy to use in the outbound direction because they create an
association on the output. We do not have equivalent expressions for
inbound direction (yet). And there may be some bugs as well, as the
inbound mappings were in fact only very lightly tested in situations
with complex inputs.<br>
<br>
Yes, the code that handles entitlements in he provisioning subsystem
is the same. The direction in the association definition works in
the same way for inbound and outbound. The problem is not there. The
provisioning code should work and that code is tested well. But the
higher level code in the model subsystem is likely to cause some
problems. But not too much problems. I would guess that this is not
*that* difficult to implement. In fact I expect that there will be
more effort in testing the code than the effort needed to write it.
MidPoint is theoretically prepared to support this. But the devil is
in the details. And even if something should work in theory it
usually takes a couple of long days and nights to make it also work
in practice. I'm sure you are well aware of that.<br>
<br>
But anyway, there is also a completely different side to this: Our
development capacity is limited. Even if this might be just a few
days to make this work, currently we have quite a lot of similar
little things in the backlog. And a lot of tiny tasks still means a
lot of time spent in development and testing. I would *love* to work
on midPoint just because it is the right thing to do (and it really
is!). But our developers have their lives and they have bills to
pay. So we need to carefully balance the work which brings us money
and the work that does not. I think it is perfectly understandable
that we are prioritizing requests from midPoint subscribers and
sponsors. If there are not enough funding coming from subscribers
and sponsors we do not have any other option than to switch
developers from developing midPoint to do deployment or consulting
work. So we have money to pay for their salaries. Which means that
midPoint development goes slower and then there is absolutely no
time for small improvements. Fortunately that does not happen often
and midPoint development goes full speed ahead almost all the time.
But even if we go full speed the features endorsed by midPoint
subscribers and sponsors are developed first and the other features
must wait. And that wait may be a very long one unless some puts his
money into it. It does not need to be big money. Even a small amount
of money can do miracles. But you see, there is no magic way how to
get the features for free. Someone has to pay for it in the end.
Subscription is the best way to do this because the subscribers are
sharing the cost of the development with other subscribers. But
there are many options how to fund the development ...<br>
<br>
Therefore, if you want to help midPoint move forward, please
consider getting subscription, sponsoring the feature or
contributing the code.<br>
<br>
<pre class="moz-signature" cols="72">--
Radovan Semancik
Software Architect
evolveum.com
</pre>
</body>
</html>