On Mon, 22 Jul 2013 12:20:44 +0200 Stephan Beal <sgb...@googlemail.com> wrote:
> On Mon, Jul 22, 2013 at 12:09 PM, Eduardo Morras <emorr...@yahoo.es> wrote: > > > ...No, not as hooks, but as plugins. I think that include a scripting > > engine is great, I'm a lua user, but force to use only one not. Allowing to > > call external have this advantages: > > > > a) Not tied to one scripting language > > b) In smp environments, the script will run on other processor (or even > > remotely) > > c) It can work asyncronous, fossil may not wait the script ends > > > > For some checks Fossil _must_ wait on the script to end. How can it do a > commit confirmation check if it doesn't wait on the results? Xcb uses an async mechanism, it creates a cookie, sends it and data to the external code, keep working. External code calls xcb, sends the cookie with the answer. Data and cookie can be exchanged through sql table. > To be clear, i often use the words hook/plugin/trigger interchangeably. They are different. A hook is capability we add to a function, as a anonymous function pointer. This way we can "hook" the any function to program flow, changing it. A plugin is a module that adds capabilities to program. For example Sqlite3 has plugin mechanism to add external aggreagate calculations. A trigger is code that executes other code when some conditions met. So the difference is that a hook allows a plugin work when the trigger wants. > > Perhaps I mixed the concept of user and role. I thought more about the > > concept of file owner. By default all users owns all files, but some roles, > > like superuser or project architect, own some files or dirs and only > > him/her/it can modify them. > > > > i think that would be impossible to implement properly in a DVCS (it would > be possible in a centralized SCM). When i clone your repo, i need access to > ALL of the files i cloned. If i cannot check out or modify certain files > just because you "own" them, the repo is useless to me. It means that if a > developer dies (as they occasionally do) then all of his locks are there > forever. This doesn't sound realistic to me. One of the things fossil > promises which other SCMs do not is "forever" - it's data format is > designed to outlive the software, which means that in 200 years someone > could read the fossil data format, import an ancient sqlite3 fossil DB into > his sqlite27 db, and get back to work. Except that now he can't make > changes because the files in the repo belong to another user ;). That's why I said I confused user with role. The role owns the files, not the user. Currently, a user without wiki role capabilities can't modify the wiki files. Similar, a C developer role can modify /src dir but not /documentation or /sql, the DBA role can change /sql but not /src and similar. Role info is already exchanged in pull/push/sync, user info not. So in your scenary, a user can get the role capabilities and access them. The problem is that a user is admin of his own repository file and can set whatever s/he wants and access everything. A global dvcs role and user data can solve this, not allowing this user make changes in public branches or trunk directories of central repo (or other users repos) if s/he has no privileges to do so. --- --- Eduardo Morras <emorr...@yahoo.es> _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
