Skip to content

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 ViewSets and such and move these to the application developer - saving time and support