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