<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09/27/2013 03:44 PM,
Belleville-Rioux, Vincent wrote:<br>
</div>
<blockquote
cite="mid:0AD36E0192997748BD28BC68B14C75D0036349@Lettre.gst.uqam.ca"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<style type="text/css"></style>
<div style="direction: ltr;font-family: Tahoma;color:
#000000;font-size: 10pt;">It might be better to add that
suggestion to the wiki because as I didn't expect to test
midPoint that much when I first stumbled upon it, I didn't care
about creating my own copies of the configuration files.... So
with my recent editing powers on the wiki, I went ahead and
added a notice before the "Basic User Management" section of
both First Steps pages.</div>
</blockquote>
<br>
Thanks. Maybe I would need to think more about the way how to
maintain midPoint configuration in long-running project and maybe
create a separate wiki page for that.<br>
<br>
<blockquote
cite="mid:0AD36E0192997748BD28BC68B14C75D0036349@Lettre.gst.uqam.ca"
type="cite">
<div style="direction: ltr;font-family: Tahoma;color:
#000000;font-size: 10pt;">
<div>It is really not a priority at all but maybe, just maybe,
it would be nice to see inbuilt configuration files
versioning. You could keep the as-sent XML file when it
passes validation and just show the parsed-and-renamespaced
version as a view-only textarea below. That way, editing and
doing small changes on test systems would be much easier and
also more live-like.</div>
</div>
</blockquote>
<br>
Interesting idea. And it is maybe not that difficult to implement.
But there is a catch. MidPoint is modifying some of the objects as
part of its normal operation (e.g. changing status of resource from
"down" to "up"). This modification is done from the inside and
actually it is not represented in XML (we are not using XML
internally). The configuration can also be changed using deltas
executed from the web service. In such cases the as-sent XML files
will no longer be valid. And it will become more problematic when we
add REST and JSON support. Even though there may be way how to
synchronize these versions I don't think that is the correct way to
go architecturally. It gives us more than one version of the
"truth". We risk that these will get easily out of sync.<br>
<br>
Therefore I can see only two good ways out of this mess:<br>
<br>
1: Fix XML libraries. This may be very difficult and messy path. And
it may be likely that we end up with rewriting XML libraries from
scratch. And maybe even "extending" XML itself. But I'm quite
persuaded that XML is FUBAR. Therefore I think that this may be a
wasted work.<br>
<br>
2: Switch to different representation format. The obvious choice is
JSON . JSON is (very) far from being ideal. But so is XML. And JSON
has a nice property that it avoids some of the most severe XML
drawbacks (namespaces, comparison, schema) by just ignoring them and
not implementing them at all. Therefore we are free to provide our
own mechanism which will (hopefully) avoid the XML-like pitfalls.<br>
<br>
I have expected that getting away from XML might be necessary. This
was one of the key point of midPoint architecture very early in the
project. Therefore we have created a component named "prism" that is
a data representation abstraction. It should allow us to quite
easily change representation formats. MidPoint code does not use XML
directly. It is working with prism objects. Prism objects are
translated to and from XML at system boundaries such as import page
or web service. Therefore adding support for JSON should not be that
difficult. However, we need to add namespace support to JSON. And we
will also need to stick to XSD for description of our data model (as
JSON schemas are currently not really usable). This will be a tricky
thing to put together. But I guess it is much better investment of
time than sticking to XML.<br>
<br>
Note: Even tough we switch to JSON the XML representation will still
be supported (with the current drawbacks). MidPoint should also be
able to seamlessly convert data between representations. Therefore
if you now invest work into XML configuration files your work will
not be wasted. You can switch all your configuration to JSON later
if you like to go that way. Or you could stay with XML. Even though
we want to add JSON support really soon we do NOT plan to drop XML
support in any foreseeable future.<br>
<br>
<pre class="moz-signature" cols="72">--
Radovan Semancik
Software Architect
evolveum.com
</pre>
</body>
</html>