From: p d. t. <pdo...@an...> - 2005-01-28 04:40:45
|
I am moving this to the devel list where it belongs. >>>3) get rid of frames in squirrelmail >>> >> >>Jimmy already did a bunch of work on this. I don't think anyone tested >>it out. My feeling is that it's probably good to go (although I haven't >>looked closely at the solution myself). Having things in branches is good >>for a lot of reasons, but if no one tests those branches out, then that's >>a bit of a problem, isn't it? :) >> >>I'd say this is especially good to integrate now, since once we go to a >>templated solution, it may be more important to have an understanding of >>how we are serving up framed/non-framed pages. > > What jimmy did was a workaround for current squirrelmail code and is not > useable if we moving along to templates. I haven't inspected that code myself, but I had the impression that it wasn't completely unusable, although I suppose I wouldn't be surprised given that a lot of the code will probably end up in the waste bin. What I would not like to see us lose is a framed view too. > Talking about it, templates needs also some brainstorming and if i'm well > informed Erin has some experiences with using a single entry page, > initiating a squirrelmail object and do the required initialisation stuff. > Personally i didn't looked at it very deep. I think this is what she has mentioned in the past: http://www.massassi.com/php/articles/template_engines/ This is very similar: http://www.sitepoint.com/article/beyond-template-engine I use something very close to this: http://www.onlamp.com/pub/a/php/2003/04/17/pear_smarty.html on a daily basis, and could offer a couple ideas for how we might want to tweak it for ourselves. Doesn't she have something already working in the template dept in smdoc? >>>4) create templates >>>----------------------- >>>Other stuff on my todo list what should be on the roadmap and we should >>>talk about: * Compose class which cooperates with the message class >>>(simplify >>>compose.php and put the message object manipilating stuff deep inside >>>classes. Also make it an extended class so we could support html >>>compose in a cleanly manner without nasty hacks >> >>The HTML_Mail plugin isn't *too* nasty (if I can get the dev version >>out...). :) But point agreeded to. Although I think it could be fine to >>leave HTML support as a plugin, especially since there are so many >>variables to think about, and that the editor itself is an outside project >>(there is actually a 2nd one that I am going to try to integrate >>as an alternative).... and surely we don't want to take on that beast as >>our own. A related issue is that ppl are clamoring to have the ability to >>re-edit HTML-formatted emails when they reply, which is something the >>plugin cannot do w/out SM's help. > > That was my idea too, leaving the editor outside squirrelmail. > SquirrelMail should take care of the mime constructing. This means, decide > if a message should get content type multipart/mixed, multipart > alternative, create the alternative text/plain part, initiate the message > object correct in case of a reply or forward. Add the signatures, do the > quoting. add the forward header or reply citation. But we need to be careful - you are lumping things here that some people will want SM to do BEFORE they compose the message, some AFTER the send button is pressed. I like the idea the a message would be smart enough to know that it needs to create a plain text part if all it has is a HTML part, but how will it be smart enough to know? A plugin will still need to at least give it a mime type I suppose, and as such I don't think it's too much to ask for the plugin to hand it a proper message (both parts in this case). Ah, but either way I am not going to argue, I don't have a strong preference here, especially without seeing more details on what you had in mind. >>>* restructure mime handling. Make it possible to register special >>>modules for displaying certain mime types (i.e. check what we do now >>>with view_text.php, view_image.php). We should make it possible to add >>>vcard and ical viewers in the future in an easy way once we changed the >>> internal architecture regarding mime. >> >>Huh. I am polishing off the beta of the new calendar (that should be >>making its way into the devel stream once ppl are happy with it) that >>supports iCal... it would be helpful to hear more about how you propose >>such a thing so I might make the calendar provide an easy-to-use interface >>for displaying iCal attachments or accepting meeting invites or whatever. > > Basicly I was thinking about a new type of plugin (rough ideas). When you > install such a plugin it registers itself to a mime array (basicly it > looks like attachment_common.php but then class based). > After processing the mime structure and we are aware of the available > content-types in a message we should do a lookup in that array and create > the right extended class. If those plugins provide an extended class which > a bunch of overrided methods they can hook in their own viewing methods. Uh-huh. Not too different from what we have now, 'cept class-based. I like the idea - only caveats that I can think of are plugins that want to provide extra link for different kind of download for *any* mime type attachment (File Manager is one; a solution would be simply to provide another hookpoint nearby) and what happens when there is more than one plugin for a certain mime type... ? > In case of an iCal event I can imagine that instead of showing a line with > the attachment and mime type we include the block provided by the iCal > plugin with the right buttons to add an event to a calendar. Or when you > click on it it opens a calendar view. > > If we use the same semantics for our standard supported mime types we > could put all mime handlers in a separate dir. > > Encryption related mime parts like pgp signed, pgp encrypted should also > make use of it. Probably it will simplify some parts if the pgp plugin > (Brian please comment on this). > > Of course it also should support some kind of chaining because when > encryption is involved we first need to decrypt it and after that the > decrypted mime parts show up which got handled by other mime handlers. yeah, the chaining idea seems crucial as well as support for multiple handlers for one type if possible. |
From: Tomas K. <to...@us...> - 2005-01-28 07:39:51
|
> I am moving this to the devel list where it belongs. > >>>>3) get rid of frames in squirrelmail >>>> >>> >>>Jimmy already did a bunch of work on this. I don't think anyone tested >>>it out. My feeling is that it's probably good to go (although I haven't >>>looked closely at the solution myself). Having things in branches is >>> good for a lot of reasons, but if no one tests those branches out, then >>> that's a bit of a problem, isn't it? :) >>> >>>I'd say this is especially good to integrate now, since once we go to a >>>templated solution, it may be more important to have an understanding of >>>how we are serving up framed/non-framed pages. >> >> What jimmy did was a workaround for current squirrelmail code and is not >> useable if we moving along to templates. > > I haven't inspected that code myself, but I had the impression that it > wasn't completely unusable, although I suppose I wouldn't be surprised > given that a lot of the code will probably end up in the waste bin. > What I would not like to see us lose is a framed view too. http://www.squirrelmail.org/wiki/en_US/WishListFrames It is possible that frames are "so 80's", but they provide some options that can't be implemented without increasing browser requirements or having to reload entire page just to see email counter changes. There is plugin that allows it, but I suspect that it uses outdated sqimap functions. Last time I've checked NoFrames branch, there are some issues. * left column gets same color theme as right one. * I suspect that code was programmed without error_reporting=E_ALL * layout settings are controlled by administrator or selection box in login window. Current option structure allows administrative controls of user settings implemented in $optpage_data. There is no need to have frames/noframes options in conf.pl. If users have other frame preference than default one, they have to confirm that preference during each login. * patch is not maintained and stopped development of other similar patch. >>>The HTML_Mail plugin isn't *too* nasty (if I can get the dev version >>>out...). :) Please do that in near future. If you don't release plugin, somebody will do that for you. -- Tomas |
From: p d. t. <pdo...@an...> - 2005-01-28 09:48:57
|
>>>>>3) get rid of frames in squirrelmail >>>>> >>>> >>>>Jimmy already did a bunch of work on this. I don't think anyone tested >>>>it out. My feeling is that it's probably good to go (although I haven't >>>>looked closely at the solution myself). Having things in branches is >>>>good for a lot of reasons, but if no one tests those branches out, then >>>>that's a bit of a problem, isn't it? :) >>>> >>>>I'd say this is especially good to integrate now, since once we go to a >>>>templated solution, it may be more important to have an understanding of >>>>how we are serving up framed/non-framed pages. >>> >>>What jimmy did was a workaround for current squirrelmail code and is not >>>useable if we moving along to templates. >> >>I haven't inspected that code myself, but I had the impression that it >>wasn't completely unusable, although I suppose I wouldn't be surprised >>given that a lot of the code will probably end up in the waste bin. >>What I would not like to see us lose is a framed view too. > > > http://www.squirrelmail.org/wiki/en_US/WishListFrames > > It is possible that frames are "so 80's", but they provide some options > that can't be implemented without increasing browser requirements or > having to reload entire page just to see email counter changes. There is > plugin that allows it, but I suspect that it uses outdated sqimap > functions. > > Last time I've checked NoFrames branch, there are some issues. > * left column gets same color theme as right one. > * I suspect that code was programmed without error_reporting=E_ALL > * layout settings are controlled by administrator or selection box in > login window. Current option structure allows administrative controls of > user settings implemented in $optpage_data. There is no need to have > frames/noframes options in conf.pl. If users have other frame preference > than default one, they have to confirm that preference during each login. > * patch is not maintained and stopped development of other similar patch. Thanks for looking at it. I also remember it b0rked things pretty good when Jimmy first put it in, but I do wish it could be integrated if templating is farther off than another release of 1.5. I would guess that all it needs is some cleanup - the issues you identify don't sound hard to fix. Then again, I prefer frames. :) >>>>The HTML_Mail plugin isn't *too* nasty (if I can get the dev version >>>>out...). :) > > > Please do that in near future. If you don't release plugin, somebody will > do that for you. I sure wish that 'somebody' was willing to help figure out why the multipart messages it was generating many months ago were choking up SM (but not other clients). I feel like Marc when I say I asked for assistance and got none, so this is the result, it has to wait til I get the time. And with having to maintain as many abandoned plugins as I do, they all take up a great deal of time... your remark makes me feel as if you are not aware of how much time I put into this project. |
From: Tomas K. <to...@us...> - 2005-01-28 12:58:07
|
>>>>>The HTML_Mail plugin isn't *too* nasty (if I can get the dev version >>>>>out...). :) >> >> >> Please do that in near future. If you don't release plugin, somebody >> will do that for you. > > I sure wish that 'somebody' was willing to help figure out why the > multipart messages it was generating many months ago were choking up SM > (but not other clients). I feel like Marc when I say I asked for > assistance and got none, so this is the result, it has to wait til I get > the time. And with having to maintain as many abandoned plugins as I > do, they all take up a great deal of time... your remark makes me feel > as if you are not aware of how much time I put into this project. Can you provide access to your software repository or put it on SF? Maybe I have missed some email that provided that address. I don't see any progress in html_mail development. Only your words and patches that haven't made their way into any released plugin versions. How do I know if you solved variable based translation in javascript issue? How do I know if latest htmlarea code is integrated? How can I help solving those issues, if code is not publicly available? Ask for plugin snapshot every time I want to take a look at it? smallcal i18n patch was written more than one year ago. You say that it is or will be integrated into shared_calendars, but all I have is some debugging version that is not released officially. How person that written that smallcal patch should feel? How should feel person knowing that some translations break correct way of translating squirrelmail.po and manually add smallcal strings into squirrelmail.po file. how should feel person that written plugin and that plugin never made the way to squirrelmail site. http://article.gmane.org/gmane.mail.squirrelmail.plugins/6106 I don't want to insult you. I only want to see progress in plugin development that leads to releasing new plugin versions and fixes existing issues. I don't care if those versions are not perfect. People can try fixing things that exist. -- Tomas |
From: p d. t. <pdo...@an...> - 2005-01-30 00:24:45
|
Tomas Kuliavas wrote: >>>>>>The HTML_Mail plugin isn't *too* nasty (if I can get the dev version >>>>>>out...). :) >>> >>> >>>Please do that in near future. If you don't release plugin, somebody >>>will do that for you. >> >>I sure wish that 'somebody' was willing to help figure out why the >>multipart messages it was generating many months ago were choking up SM >>(but not other clients). I feel like Marc when I say I asked for >>assistance and got none, so this is the result, it has to wait til I get >>the time. And with having to maintain as many abandoned plugins as I >>do, they all take up a great deal of time... your remark makes me feel >>as if you are not aware of how much time I put into this project. > > > Can you provide access to your software repository or put it on SF? Maybe > I have missed some email that provided that address. I was not very happy in the non-consensual solution to the plugin CVS problem we talked about a year ago, although I certainly ackowledge that lack of code availability is a problem. I have been thinking (not very fruitful) about other solutions in the last few weeks. > I don't see any progress in html_mail development. Only your words and > patches that haven't made their way into any released plugin versions. How > do I know if you solved variable based translation in javascript issue? > How do I know if latest htmlarea code is integrated? How can I help > solving those issues, if code is not publicly available? Ask for plugin > snapshot every time I want to take a look at it? Availability is certainly a problem, but you can also ask me instead of just wondering to yourself. If you do not trust my words, then that is a personal problem that needs to be resolved offline. > smallcal i18n patch was written more than one year ago. You say that it is > or will be integrated into shared_calendars, but all I have is some > debugging version that is not released officially. And you can look at that code and answer this question. What's the problem there? > How person that written > that smallcal patch should feel? How should feel person knowing that some > translations break correct way of translating squirrelmail.po and manually > add smallcal strings into squirrelmail.po file. I have made it clear a number of times that this plugin will become obsolete (in so many words) as the new shared calendar plugin becomes available. I have made numerous posts offering beta code of that plugin and many ppl have taken me up on the offer. > how should feel person that written plugin and that plugin never made the > way to squirrelmail site. > http://article.gmane.org/gmane.mail.squirrelmail.plugins/6106 I am perfectly aware of this plugin and its need to be on the site. What's with all the accusations? Have you appointed yourself the boss of SM now or something? If so, when's the paycheck going to arrive? I am generally a very overworked person, yet I put in an awful lot of hours (often equivalent to a full time job) to SM in various capacities, and I resent the implication otherwise. > I don't want to insult you. I only want to see progress in plugin > development that leads to releasing new plugin versions and fixes existing > issues. I don't care if those versions are not perfect. People can try > fixing things that exist. I have a very large number of abandoned plugins, along with my own plugins, to manage, as well as all other things SM, so I tend to hit issues as they come up... and I don't always have the time to solve the issue and then wrap everything else up to make an acceptable release. My personal/professional tendency is not to release half-ass software with bugs, or to make 10's of incremental releases that really annoy admins, so that's why my releases tend to be far and few between, but the ones I do put up should be very solid. I'll think about putting code on SF if nothing else seems workable. -paul |