[midPoint] RE : Oh, another question

[Radovan Semancik]

On 09/27/2013 03:44 PM, Belleville-Rioux, Vincent wrote:
> 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.

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.

> 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.

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.

Therefore I can see only two good ways out of this mess:

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.

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.

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.

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.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20130930/e1590a3b/attachment.htm>