ubercart-convo

chx: rszrama: litwol: let's chat about pm.
chx: rszrama: well, as usual, you forked a project (or created a parallel, does not matter what you call it) without talking to anyone about it
chx: rszrama: I found the  ubercart vs ecommerce scenario sad
chx: rszrama: but this pm_lite is not something i will let pass
chx: rszrama: I would much rather see some discussion than releasing another PM project. Why did you this without talking to litwol or me?
rszrama: chx: honestly, I was using it to bone up on my Drupal 6 skills and thought it would be useful as an alternative to a fully integrated module like privatemsg - the concept is also entirely different
litwol: rszrama: okey few fundamental issues
rszrama: I also got a forum post about PMs as nodes getting shot down before
litwol: because you are taking big assumptions
litwol: regarding the "fully integrated" blah blah
litwol: i've spent considerable amount of time researching and now implementing a private messages modules or system, what ever you want to call it, that starts from minimalistic core and expands further through very flexible architecture
litwol: there is work in place to build something that you just took on a parralel
chx: yeah -- even without the unfortunately misunderstaing about node access, nodes for PM might not be the best solution. THis is why we need to discuss.
litwol: without consulting
chx: And people who does not do this research hear "nodes" and then run over to a solution which may be worse
chx: but here the problem is even simpler to understand : you need to add a lot less to a single message than the node system would allow
litwol: and even if you manage to write well performing pm_lite code and queries. simple fact of adding extra records to the node table (especialy something as popular as private messages which tend to add million or rows), you diretly impact on EVERY OTHER node query that is executed which isnt related to pm_lite
chx: rszrama: there are a LOT of things you can add to a node which makes no sense for a pmsg
chx: rszrama: the big problem is that you are providing a module which, for the casual user looks good but it is likely not
chx: rszrama: this saps resources from privatemsg which is definitely not what we need
chx: rszrama: as said, you are infamous for this behaviour aka. ubercart.
itwol: in the d6 version of privatemsg i am using a lot of advanced d6 concepts and even take things further on some cases. its a good play ground for experimentation. and i would much rather us to work together to make something great rather than working against eachother
chx: rszrama: I am asking you to reconsider and unpublish this and rather help privatemsg. You did _awesome_ UI work in the past please help us further.
rszrama: perhaps to clear up any ill will that may be pre-existing - I'm paid to do Ubercart; starting a new e-commerce system wasn't just a random idea I had
chx: well, the same stuff could have done with E-Commerce, I believe... but this is now the past
chx: but please note that the compiz and the beryl projects merged
chx: I urged you guys in Barcelona to cooperate
rszrama: re: PM Lite, though, while I would've still worked on this for my own purposes, the primary one being to get a handle on all things node API related in D6, it sounds like I should've tested the waters for the D6 work on privatemsg before posting willy nilly
chx: It hurts to see duplicated efforts
litwol: d6 nodeapi is no different than d5
rszrama: I've never really used it there, either I guess
rszrama: aye - and to be honest, I don't consider it a competition - but I understand the feeling of divided efforts
litwol: i'm not talking about competition
litwol: i'm talking about using the right technology for the right feature
litwol: and quite frankly nodes are not it
rszrama: was there a discussion on the issue?  I'd be interested in reading through it if it's available
litwol: that is not based on the random bashing i got for suggesting that in public[09:22am] litwol: this is based on weeks worth of node access system research and more
litwol: discussion of pms as nodes?
rszrama: aye
rszrama: although it sounds like your decision may have been decided otherwise
 rszrama: heh
litwol: it all been discussed in irc over the course of multiple weeks
rszrama: *elsewhere, not otherwise
rszrama: gotcha
litwol: chx: wasnt pointing fingers
litwol: rszrama: your reasoning for experimentation can be well satisfied within the privatemsg project
litwol: there is ALOT to do and i am focusing on other areas, and you can focus on areas you want to practice with
rszrama: honestly, I almost considered it job done and was going to use the knowledge to write a gradebook module for my wife   - many thanks to chx, btw, I love the new menu system
rszrama: -aside- it fixes the My inbox (2) links very easily - it no longer counts messages you're currently viewing
chx: THAT is a valid concern!
merlinofchaos: pm as node would destroy the performance on any big site that needed private message.
rszrama: catch: hook_db_rewrite_sql - atm, your concerns are addressed
moshe_work: merlinofchaos: you don't have to store them indefinately
chx: I would much much rather see pm a very small database item and add stuff as ncessary.
moshe_work: and 'destroy' is a bit much
catch: Nor do I want a bad node_access module showing people's personal messages (IMO worse than restricted content)
chx: rszrama: not for admins, no!
merlinofchaos: moshe_work: Doesn't matter. It means you turn on access control which means every node query you ever make is now filesorting.
catch: rszrama: the users on my site would throw a fit if they knew I could read their pms.
chx: catch: rszrama does NOT use the node_access table
litwol: the architecture i am using in privatemsg d6 version allows as much flexibility nodes do through the API of privatemsg. so if user X wants a node feature on privatemsg he could easily enable it through a wrapper module. however those hooks are disabled by default to avoid overhead, and avoids placing records in node table which slows down overall node_access process.
chx: rszrama: but node admin queries do not run db_rewrite_sql imo.
rszrama: catch: I can read a PM in phpMyAdmin just as easy as I can through an admin account
rszrama: chx: I see
moshe_work: merlinofchaos: thats a porblem with node_access rewrite() or whatever it is called
moshe_work: we should fix it (no idea how yet)
catch: rszrama: not quite as easy, you'd still have to connect uid to user yourself.
moshe_work: and the administer nodes permission has always been a problem
merlinofchaos: moshe_work: Yes, it is. I've thought long and hard on how to fix it, and I still haven't figured out how.
IslandUsurper: simple JOIN, catch
moshe_work: that perm is a is a catch all
catch: IslandUsurper: I know, but some admins on my site don't know what phpmyadmin is.
moshe_work: a shortcut - like uid=1
catch: IslandUsurper: hence, much harder for them.
moshe_work: we need more granular perms
chx: in the short run
chx_food: before we redo the whol admin node perm
moshe_work: so, there are some drawbacks to PMs as nodes but those should be fixed in node module
litwol: moshe_work, merlinofchaos: david strauss has content access architecture in mind to fix node access
chx_food: i would like to see pm_lite cease
rszrama: litwol: so, the main reason I went w/ the node API was b/c I didn't have a lot of time to spend on this module and didn't want it to suck up time later - now, you're going to be stuck updating, maintaining, and expanding a custom architecture when using the node system would mean the whole community does work for you
catch: litwol: rszrama I'd even like to see pms md5ed in and out.
chx_food: and efforts unite
chx_food: this is all i ask for
chx_food: anyways: I need to eat.
litwol: rszrama: you are jumping to conclusions based on your previous experiences
litwol: rszrama: you are not even asking me of my road map, the architecture, nothign
chx_food: rszrama: the whole community does NOT work for you how can you not understand that most node related activities are not needed?
litwol: rszrama: you just plain out disregard privatemsg.
rszrama: litwol: it was just a personal assumption
litwol: rszrama: personal assumtion that targeted me
litwol: so be so kind to ask first
rszrama: litwol: _le sigh_ - personal assumption that I didn't want to have to do that, so I used the node system
litwol: and this is what i'm trying to get across here. we should unite efforts instead, because it is obvious to me you've based your decisions again on assumption with absolutely no research of the api you are using
chx: rszrama: there are people working on the privatemsg module and soon module family , you are not alone -- but you are hurting these people.
rszrama: litwol: whether it should've been made into a project or not, it's there now, and if that can be used in any way to help privatemsg, count me in
litwol: great. complete disregard to all the points raised
litwol: rszrama: i already said how
litwol: rszrama: pm_lite needs to merge into privatemsg
litwol: use what you learned there and put it into privatemsg
rszrama: litwol: not complete disregard, just pre-occupation - I'm at work and trying to put out Uber 1.0 - and I'm hungry for lunch
litwol: to benefit the existing userbase of the privatemsg module
rszrama: all my actions aren't personal attacks or community defiance
litwol: saying it doesnt make it so
rszrama: I'm not sure what merging would look like, so you can outline that in an e-mail along w/ the work completed and reasons for not making PMs nodes - I'll help however I can...

Then followed up by IslandUsrper to re-ignite the ignorance...
IslandUsurper: I am amazed that no one seems to think that forking is a good thing
litwol: IslandUsurper: who's going to maintain the fork?
IslandUsurper: Ryan
beeradb: IslandUsurper: it's great if there's a reason for it, but forking to add a feature that could be added to the original module doesn't make a lot of sense... it's highly dependant on the person who forks, and the reasons they forked for
IslandUsurper: it's not a feature that could be added to the module. it's a completely differnet way of doing it
litwol: hyet another assumption
IslandUsurper: tell me how it's wrong
merlinofchaos: IslandUsurper: There is a shortage of people who can/will maintain modules. Forking highlights that shortage.
beeradb: IslandUsurper: I didn't say it was wrong, I just said it was probably wrong:)
merlinofchaos: IslandUsurper: It ends up creating duplicate effort and splitting the community. Particularly bad forks can be devastating for both branches. Other times, one fork just crawls off into a corner and dies.
japerry: IslandUsurper: plus, Ryan already maintains a bunch of other modules, many which have become outdated and some hes deciding to stop developing at all
litwol: i just want to point out that he said so himself that he will _not_ maintain the module. the only purpose for it was to allow the community to devel for it since its using nodeapi
IslandUsurper: litwol, that's not what he meant. maintaining pm_lite means keeping up with the nodeapi, which the community will continue to improve
litwol: IslandUsurper: i'm glad to be wrong. but at the same time it is clear to me that just not enough thought was put into choosing the right tool for the job
chx: litwol: I am going to escalate this problem to the developer list asking for a delisting of pm_lite
chx: litwol: could you please help me with a write up of your research
litwol: sure i could point out some of the things i found and the alternatives