On Monday, March 2, 2015 at 11:39:18 AM UTC+1, Tobias Beer wrote: > > Mario mentioned that managing recipes, bags, even users may not entirely > be in the scope of the TiddlyWeb API. >
You are right. "not entirely". As Chris mentioned, there are several server side plugins to manage users and access rights for TiddlySpace. ... but imo the needed authentication and authorisation increases the complexity a lot. Especially the access rights "drop privileges" approach for TS is complex. I pointed to my console <https://dev.tweb.at/console.html#host:https://dev.tweb.at/api>, where you can see, that managing recipes, bags and policies is easy. ... but creating a generic and simple to manage access concept for the basic recipes (TiddlyWikis) and the r/w structure is hard. > I guess one big question is: What do we mean by collaboration? > Exactly. And here the scope of the target audience comes into play. - Do we want something that I called "TiddlyWeb at Home", - which basically _must_ be a single click install. - The store needs to be file based, because we know form all other discussions. Standard users refuse databases. - Backup needs to be easy. aka file based and may be using Dropbox or friends ... - It needs to be easy to manage small groups. 1, 2, 3 up to 10 concurrent users. For this group we could design a very basic "recipe" structure, with (kind of) fixed bag names. - which makes authorisation (r/w access) simpler. We can keep the authentication simple. - username / password ... http for local networks with no internet exposure. - https for settings with public internet connection. ------- If we target small businesses, IMO this is a completely different area. - Authentication systems may already exist. eg: single sign on, oauth, LDAP ... - Databases may be possible _but_ "disaster recovery" is a very hot topic here. - Handling database backups is more work then file based backups .. - An authorisation structure may exist and needs to be adopted ... ... do we want this? IMO here we hit a big problem. ... I count schools as small businesses. .. They always have @business like requirements but the admin resources and the complexity needs to be @home like. Having a look at the group discussion, education users are always the first ones, that want a file TW to be multi user accessible. .... What does it entail? > > - user setup / registration / authentication? > > This are 2 different topics. - setup / registration - @home: can be done by an admin. - @business: should be possible for the user. So web UI needed. - authentication is used to verify, that you really are, who you pretend to be. - @home ... imo will be a much simpler structure. cookie based. - @business ... will depend on the usecase and imo cant be laid out up front. > > - "shared", multi-user wikis > - access rights ? r / w > - admin vs. editor vs. subscriber? > > Especially dynamically share / include / combine bags may introduce higher complexity and will always depend on the usecase. > > - user wikis / spaces / profiles > > This is mainly a naming convention, which has to be agreed upon. > > - "space" inclusion > > Makes the UI and access r/w configuration much, much, .. more complicated. .. but projects like AMBIT or SunyIt rely an behaviour like this. ... Just some thoughts. mario -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/d/optout.
