Rest Framework LDP
I've opened a number of issues for ways in which DjangoLDP could be refactored to be more in line with Rest Framework's common usage. I gave an overview of these issues here management/core-team#13 which raises some common issues with nested fields and the design conflict between automatic vs easy-to-extend
Since then we've actually forked from Django itself for some auto-deployment features. Whilst I can see that the auto-deployment features are useful, I think that we could more cleanly repackage DjangoLDP into at least two components:
- Rest-Framework-LDP: extending Django + Rest Framework features to provide the building blocks for an LDP app - I think that ideally this would only include a few things from the
Model
, a (refactored) LDPSerializer and LDPAPIView and anything else loosely like that - Django & Rest Framework tools extended for Linked Data needs - Sibserver-LDP: to leverage Rest-Framework-LDP to include the things like automated deployment which we need in Startin'Blox applications
With regard to the specs I think that things like the "Permissions classes for WebACLs" should be pushed into other packages. It's undoubtedly useful for Solid but for example there are other efforts in the linked-data ecosystem which aren't using WebACLs (documentation/specifications#8 (comment 61292)). I'm sure there could be other separations
Ping @sylvain @balessan this is the direction I eluded to during our call last week
My dream scenario would be to be given 1 or 2 days of funding to make some headway on this and see what can be done easily and then develop a bigger scope from there
My main objectives are:
- cleaner definition and separation of concerns
- allow the use of a "lighter" DjangoLDP which doesn't replace Django
- moving clients with bespoke needs to writing bespoke code will save the core team time and support
- general flexibility
- longer term I think it may be more sympathetic for the use of LDP and DRF features not currently accommodated (e.g.
APIView
, capability-based security) - longer term we may be able to phase out the monolith automated
ViewSet
s and such and move these to the application developer - saving time and support