From GregariusWiki
[edit] Logfile of the 2006-05-19 IRC session about MultiUser design
mbi - 'ning
akalsey - hey
mbi - hello
akalsey - Thoughts on MU... One thing that will bee needed is individual settings, and probably the ablity for the admin to determine which settings should be changable by the user
akalsey - It might make sense to go the route that Wordpress took, at least for the first release.
mbi - yes. Or maybe have a set of user-defineable settings and another one only the admin can change
akalsey - Wordpress MU is essentially a separate WP install for each user.
mbi - so each user has his own database tables?
akalsey - And then there's an admin UI on top of that to manage the different installs
akalsey - yes
mbi - well this makes sense in WP, but we have potentially the same data over and over again
akalsey - true
mbi - e.g. if several users subscribe to the same feedds
mbi feeds
mbi - and it *could* be interesting to access other users's items while searching
mbi - or other users' tags for suggestions
mbi - and I frankly can't see a proper way to achieve this in a multi-table design
akalsey - Okay, so all tables need either a user column or a table that joins users to the table
akalsey - probably the later
mbi - yes, user-id all over the db
mbi - the question remains, should we have several instances of an item, if more users subscribe the same feed?
akalsey - no
mbi - problem is, a plugin can change the content
akalsey - so we need a users_items table that joins users to items
kdz13 - well, you'll need multiple unread fields
kdz13 - per item
akalsey - does it change content on insert or output?
akalsey - The unread flag would go in users_items
mbi - akalsey: both
mbi - kdz13and what said
kdz13 - it's all about what I said
akalsey - So plugins that change data in import, should probably only be available to the site admin
akalsey - and really, how would a non-admin install a plugin anyway?
mbi - oh my, so we would have to restrict certain plugin hooks on a per user-level basis
mbi - good point
akalsey - BUT, if the admin installs a bunch of plugins, the user needs to be able to enable or disable them
akalsey - First question that needs answering for MU is what's the use case?
akalsey - Are we trying to make this so someone can build a public reader to compete with bloglines et al?
mbi - why not.
akalsey - or are we trying to give people the ability to build a reader for a smaller community, like all the folks they work with
akalsey - because really, the two options will change how we do things.
akalsey - If a public reader, the end user doesn't need lots of settings, plugin control, different themes, and all that
mbi - well, both options would be interesting, but I think the first one includes the second one, if you see what I mean
akalsey - Not really. The first one is probably easier
akalsey - we have to expose less admin stuff to the end user
mbi - oh, I was thinking performance, there
mbi - one thing we could do would be to design the database schema
akalsey - Still, I think we need to decide what the goal is first
akalsey - The schema would be different for different goals
mbi - I'm not sure I get your point about the first one being easier, actually
akalsey - I think the "public install" goal is easier because there's less need for individual settings, for individual plugins, for individual themes, etc. The site admin makes those choices and the user just adds feeds.
sameerd waves hello
mbi - sameerd: hello!
akalsey - no waving, join the discussion!
sameerd - I'm catching up.
mbi - akalsey: ok, so I think we should have a single admin
mbi - being able to install themes & plugins
mbi - what you said, actually
mbi - that'd be a good start
akalsey - The "community install" is more for me to create a reader for everyone in my company, my family, my school, my web site, whatever
akalsey - that I think is hte more compelling use case, but is much more complicated.
akalsey - So I suggest we go with "public install" first and then get to "community install"
kdz13 - I think that you need to ask all the people who have been clamoring for this feature what they want/expect
kdz13 - it's hard to get behind something that you'll not be using personally, at least it is for me
akalsey - Do we know who they are and how to reach them?
sameerd - akalseyI agree with about a public install
kdz13 - lol, probably not
sameerd - the users can select different themes (we can make that cookie based)
mbi - akalsey: yes, I have a couple mails laying around
akalsey - My thinking here is that we eventually have the whole banana, but we start with the low hanging fruit. (to mix some metaphors)
mbi won't it be harder to go for the whole banana, if we start working on low-fruit picking?
mbi - (now why has my irc client made an action out of my question?)
akalsey - Okay, so we move toward the whole enchilada while getting low hanging fruit. I've never had a fruit enchilada, but I'm willing to try it.
mbi fetches a draft from the fridge
akalsey - Ohh, grab me one too
kdz13|gone - see ya
kdz13|gone - have fun with this
jtokash - I'd like to switch my vote (if I even have one) from Ajax to public install.
jtokash - That would bring a lot of dev attention to gregarius.
sameerd - I think a project ending up in having each user able to customize their own version of gregarius completely would be too complicated
sameerd - it would be akin to building our own bloglines or wordpress.com
sameerd - and if we did something like this, the single user people will suffer, because the optimizations you do for both things will be different
jtokash - agreed
sameerd - so I would prefer something like, admin user can do everything
sameerd - and can have different levels of users for the other users
jtokash - Couldn't you do admin approves themes and plugins and users select?
sameerd - all users can switch their own themes
sameerd - yes
mbi - right, so where is the boundary between the two models? What will a user be allowed to do in a public install?
sameerd - but users cannot install anything
sameerd - if the admin says the user can add feeds. the the user can add
mbi - akalseythey can't anyway, because they dont have FS access, as said
sameerd - what is FS?
mbi - filesystem
sameerd - you mean DB?
mbi - no
sameerd - oh
sameerd - we are writing things to files?
mbi - well, to install a theme or a plugin, you have to download it first
sameerd - Ah no. they cannot install anything
sameerd - only admin can install things
mbi - my point
sameerd - users can add feeds
sameerd - if the admin says so
sameerd - we could allow users to select plugins that the admin has installed
sameerd - but
sameerd - that would make things too complicated IMO
sameerd - perhaps we could only allow themes to be selected
jtokash - We'd have to remove the ability for plugins to affect the feed retrieval proces
sameerd - Yes only plugins that affect the output or something
mbi - sameerd: what does the md5 field in the items table store, exactly?
sameerd - mbi: that depends
mbi faints
sameerd - one sec. let me look it up and give you a precise answer
akalsey - sameerd: What would the point be of a public install that didn't allow the user to add feeds?
akalsey - how's that different than what we have now?
sameerd - akalsey: user's cannot select themmes
sameerd - and read information the way they like it
sameerd - well we let the admin decide, what they want the user to be allowed to do
sameerd - mbi: md5sum stores the md5 of the description
mbi - before or after it was filtered by the plugins?
sameerd - mbi: definitely before
sameerd checks
mbi - too bad
sameerd - mbi: why?
mbi - because if it was *after* we could assess whether we need to insert a new item or not
sameerd - This is a global device to find out if a feed has changed its description. It should have no bearing on users
sameerd - if you want to do that, then you should create a new field for that
mbi - e.g. if the md5 matches that of another user, we wouldn't have to re-insert the same item
sameerd - well we need to store the original somewhere too
sameerd - otherwise we would not know if a feed had updated or not
sameerd - Gregbot: talk
Gregbot - fine
mbi - I start regretting our moving to the db-cache model
sameerd - we can move back pretty easily
sameerd - we just need to use rss_cache.inc instead of rss_dbcache.inc
mbi nods
sameerd - but I think what we need to do first is outline what our goals are
sameerd - and then start thinking of ways to implement them
mbi - why, our goal is twd
sameerd - yeah of course but our short term goals with this MU design
akalsey - Gregbot: TWD?
Gregbot - dunno
sameerd - akalseyDo we want to build a bloglines thing? or a public install type thing like suggested?
mbi - omg
mbi - I vote for public install
sameerd - I like the latter because that will also optimize things for single users (like me)
mbi - and me
Gregbot - Fri, 19 May 2006 14:25:11 -0500: Design:Multi-User :: @
Gregbot - Fri, 19 May 2006 14:23:00 -0500: Roadmap :: @
sameerd - So now we only have to define what users can and cannot do
akalsey - the "public install thing" is the same as the "Bloglines thing"
sameerd - Gregbot: silent
sameerd - Gregbot: quiet
Gregbot - done
mbi - Gregbot: TWD?
mbi - Gregbot: talk
Gregbot - sure
mbi - Gregbot: TWD?
Gregbot - don't ask me
sameerd - akalsey: doesn't bloglines allow plugins?
akalsey - no
sameerd - oh ok then.
mbi - Gregbot: TWD is Total World Domination
Gregbot - done
sameerd - so then the question was whether we want to build something like wordpress.com
akalsey - all the end user can do is add feeds, and set some feed options
sameerd - or a public install
sameerd - wordpress.com allows plugins right?
Gregbot - Fri, 19 May 2006 14:25:11 -0500: Design:Multi-User :: @
Gregbot - Fri, 19 May 2006 14:23:00 -0500: Roadmap :: @
sameerd - mwatch
sameerd - Gregbot: mwatch
sameerd - Gregbot: rmwatch
Gregbot - can do!
sameerd - sorry
sameerd - so basically I think we should make a list of things we allow the non-admin level users to do / not do and then modify gregarius to do that
sameerd - I think people will be happy if all the end user can do is add feeds and set some feed options
mbi - and pick his theme
sameerd - yup
jtokash - I think we'll see a lot of plugin functionality moving into themes
jtokash - like double click to read
jtokash - if users aren't allowed to choose plugins approved by the admin
akalsey - I don't even see the need to allow the end user to pick themes.
akalsey - For most people, whatever comes up the first time is what they use.
sameerd - well some people prefer 3 panes and some people prefer river of news
sameerd - and people feel pretty strongly about it
akalsey - true
jtokash - theme choosing is critical, in my opinion.
sameerd - so atleast those two we should offer
sameerd - jtokashI agree with
sameerd - switching themes via ajax (like feedlounge) would be cool
mbi agreed. I must be the only user in the world still using the default theme
akalsey - quick survey, which theme do you use?
jtokash - In fact, I think that theme should be cookie based so a given user can see a different theme on each machine they use.
sameerd - akalseyI use 's theme
sameerd - which is just css to the default theme
jtokash - I used to use frames, but frames doesn't work with the new build and I haven't fixed it yet
mbi vanilla
sameerd - but I started out with lilina's theme
jtokash - So, I'm using the default theme right now.
mbi jtokashhighfives
akalsey notes that Simplicity 1.0 is under development and contains a LOT more functions, including inline feed setting editing
sameerd - akalsey: cool
sameerd - but the lilina theme is quite popular
akalsey - Maybe I should make a public svn repository for it.
sameerd - there was alot of demand for it, (atleast when I hosted it on my website)
mbi - akalsey: why, just store it along the rest of the code in the greg svn
sameerd - or you can store it in a branch if you don't think it is ready for the trunk
akalsey - I could, but I'm a little concerned about tying theme releases to greg releases
akalsey - maybe a themes repository in the greg svn would be a good idea
akalsey - GregForge
mbi faints again
sameerd - What do you guys think about adding something like dojo's toolkit or other ajax framework to gregarius
sameerd - it would help when building themes
akalsey - from a theme standpoint, I can use dojo even if it's not in Gregarius
sameerd - anyway this is offtopic.
akalsey - just include it in my theme
sameerd - akalsey: Yup. but see we have to do something about the admin interfact
sameerd - and ajaxify all that.
sameerd - and I think a toolkit will help
sameerd - there are several tickets out to improve the UI for the admin section
akalsey - sameerd: I'm playing with some admin interactions in simplicity now
akalsey - Simplicty hasbeen downloaded 139 times in may
