Robert Burrell Donkin ha scritto: > i've been experimenting with modularisation of the code related to > users. i'd like to split into separate api, library and implementation > components. > > the list is a little long to fit comfortably in an email so i've > posted it to the wiki (1) . below are some comments and questions > > 1 the granularity of the components is debatable. including user > repositories, stores and virtual user tables together seemed > reasonable to me but perhaps there are better arrangements.
ok. > 2 the basic rule is that libraries can not depend on each other but > only on api's. as well as user-api, it was necessary to move domain > and dns interfaces from core into an api component. putting them > together into a domain-api seemed reasonable to me but i don't have a > deep understanding. make sense to me. > 3 the management interfaces have been placed into user-library. i'm > unsure whether the right place for the management interfaces is in the > api or in the library. IMO it's ok to put them in the library: we can move them to the API if we'll need access from another library, right? > 4 XMLVirtualUserTable, UsersFileRepository, UsersLDAPRepository were > provisionally included in library. not sure this is right but i'm not > sure that there's enough critical mass to create components to contain > them yet Creating modules with very few classes will only increase the complexity. > 5 unsure about the granularity of avalon-user-function and > jdbc-user-function. lots of small components allows precision but > perhaps might be better to aggregate into large units including all > backend implementation of the same type. for example, > avalon-backend-function including all the avalon* implementations > (AvalonRepository and so on). > > opinions? IMO it's better to aggregate jdbc-user-function to avalon-user-function. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
