I'm not sure the igloo project's implementation is better or worse than escimo ... it's compliant to the SCIM specification a few versions back. The current version has design flaws but is working well for us. I'll try to describe the differences but since the eSCIMo code wasn't functional when we forked, it's probably better to have Kiran describe what he ended up with. I've added links to the two files we started with at the end of the e-mail just to show that when we had the discussion that led to us agreeing to fork the project, neither of us had much working code and so these discussions were more philosophical and theoretical in nature ... if we'd both had more done I'm sure it would have been much more obvious that a merge was or was not possible.
My understanding was that Kiran was building a mapping framework with the that provided a SCIM "Service Provider" (server) that you could plug different persistence systems into and then map SCIM resource attributes into the persistence system. I'll let Kiran expand on his design but structurally, we ended up keeping wink in the configuration (one of the architectural mistakes I made). In the same way Kiran didn't look at our repository, I haven't kept up with what he's done either, so please let him describe his system. Does the the five minute tutorial exist (http://directory.apache.org/escimo/five-minutes-tutorial.html)? I'd like an overview too! I can provide a bit more detail on Igloo but bear in mind that I believe it needs rework too. We required the intermediate system to do much more than map attributes between JSON and persistence due to our business requirements. We accomplished this by creating JAXB annotated classes for each type of SCIM resource and letting JAX-RS unmarshall the received JSON into an associated Java object. The plan was also to use BVF annotations to allow validation of the JSON contents while the validity of the JSON structure has already proven (through successful unmarshalling) that the document's schema was valid. In order to make igloo more of a tool-kit, it's broken into modules that are individually useful. At least initially, the Penn State business logic won't be included since that's the part that isn't SCIM compliant ... you can still build a fully functional system from the igloo components and we'll not only offer a demo server but will host one for the SCIM community on PSU servers. We'll also be building a "SCIM Studio" with various tools ... I had previously promised the SCIM team I'd publish a "filter builder" based on the lexer-parser in our system but we'll also provide linting, customization and more. In any case, as it's cleaned up and has the architectural repairs done, I'll be checking it into Github (for now). Now for a bit of good news ... I think we can help with the Kerby client code. I'll have to dig around with some of the POC work I did using the Apache DS Kerberos protocol code but I think that's a pretty exciting project! None of this answers the Colm's question related to making these projects live with each other (married or not) under one roof. I'll leave that to your team! All the best, Steve P.S. Here are the links to the two files we started with: http://svn.apache.org/viewvc/directory/escimo/trunk/server/src/main/java/org/apache/directory/scim/UserService.java?revision=1500438&view=markup&pathrev=1503246 http://svn.apache.org/viewvc/directory/escimo/trunk/common/src/main/java/org/apache/directory/scim/ProviderService.java?revision=1503246&view=markup&pathrev=1503246 On 04/22/2015 08:13 AM, Emmanuel Lécharny wrote: > Le 22/04/15 12:42, Colm O hEigeartaigh a écrit : >> I don't think that having two different implementations of the same thing >> at Apache Directory is a good thing. However, it's certainly not unheard of >> for a project to replace an older codebase with a new donated codebase for >> a new major release, if there is a compelling reason to do so. > As a matter of fact, Kerby is the perfect exemple of such a situation ! > > >> For example, >> maybe the architecture of the older project may be too limiting etc. > or the donation is more advanced. > -- "One longs, in reading your code, to walk on all fours" - Voltaire
