Latest Posts in: Hastymail 2 ideas

Re: Plugins should support global themes (plugins) posted by sailfrog

Wed, 16 Jan 2008 11:18:38 -0600

we could allow a plugin to include its own additional css file during the page init in which it has hooks.

re: location of hook requests (plugins) posted by sailfrog

Wed, 16 Jan 2008 11:01:40 -0600

We than have to include a file per enabled plugin on login at least, which I don't really care for that much. Maybe this is the bit we should automate via an install procedure of some sort.

Plugins should support global themes (plugins) posted by Petaris

Wed, 16 Jan 2008 10:47:34 -0600

Plugins should use the same theme or color scheme as the rest of hm2. At least as a default option. There could be reasons to use a special one if it was a photo album or something.

location of hook requests (plugins) posted by slushpupie

Wed, 16 Jan 2008 10:47:01 -0600

I think the difference between your idea and mine is where the hook requests come from. I look at the config file as something the admin is going to read and modify. I dont think the plugin hook requests belong there, since they are not really configurable. Which means the hook requests should come from within the plugin source itself, which means the plugin source needs to be included.

sort of (plugins) posted by sailfrog

Wed, 16 Jan 2008 10:40:55 -0600

Good point about needing an init function, defining the hooks based on the page should not be a problem. Also we want to provide additional means to create stand along pages within the site (not ones that hook into existing pages) so we need a mechanism for that, which I already have floating around in my head. It would be very much like the existing mechanism for outputting pages within framework, but encapsulated into the plugin include file. I think you have an extra step in the initial process. What if we have only the main plugin config file, parsed at login and stored in the session. There is no need to parse individual files from the plugin until a hook (or init for that page) is called. Then when we hit a hook execution point we include the file associated with that hook/plugin and run a predetermined function in the plugin file. There are no arguments to the hook function. Everything they might need to do can be done by including the global $user object.

Plugin config syntaxes (plugins) posted by slushpupie

Wed, 16 Jan 2008 10:33:13 -0600

Here are some example syntaxes for the plugin config http://docs.google.com/Doc?id=dpwkdp9_1qdndvkdm

The life of a plugin (plugins) posted by slushpupie

Wed, 16 Jan 2008 10:30:59 -0600

So here is my thought on how a plugin will work:User logs in, main config file is parsed out, which includes plugin configs.Baisc syntax:$plugins['pluginname']['key'] = "value"; the $plugins array is itterated though, for each element, an array is expected. What goes in there is up to the plugin author, except for the manditory "enabled" option. If $plugins['pluginname']['enabled'] is anything but true, the plugin will not be loaded. This array is then stored in $_SESSION once its all been parsed. The config will not be parsed again during the session.Then HM does include($pluginname+"_src.php") and calls $pluginname+"_register"() which is expected to register any hooks (which will be documented). This will only be done once per session.Each time a hook is encountered (list_folders, whatever) from that point forward, $pluginname+"_"+$hookname($args) is called. Future page loads only call hooks. One such important and spcial hook will be "init" which is called before other processing is done at each page load (so the plugin can initialize database connections, or whatnot). But the "init" hook will only be called if the plugin has other hooks to be called on this page load. This means HM needs to know very early in the process what hooks will be called on that page load.

plugins posted by slushpupie

Wed, 16 Jan 2008 10:19:04 -0600

Ok, so here is the plugin topic thread.

yup (General Thoughts) posted by sailfrog

Wed, 09 Jan 2008 15:06:33 -0600

I am starting to sound like a broken record but the framework provides the ability to layer in features like a calender nicely, and it just so happens I have yearly, monthly, weekly, and daily views already written for it. Unlike this site hastymail will not be using clean urls so the logic will need some alteration but not much. Then we can look at event scheduling, permissions, import/export etc.

Hastycal! ;) (General Thoughts) posted by Petaris

Wed, 09 Jan 2008 14:54:03 -0600

It would be cool to have an ical compatible calendar module for Hastymail. :) - Petaris "The World is Open. Are You?"

Wacky idea (IMAP ideas) posted by slushpupie

Tue, 08 Jan 2008 21:28:32 -0600

Ok, here is a wacky idea, feel free to shoot it down if you think its really bad. If we use ajax, could it be possible to open some http session between the browser and web server that maintains the imap session (persistence) and then other calls communicate via IPC on the webserver end with the persistent imap session? As long as that http connection dosnt close, it can do work in the background, right?

STARTTLS (IMAP ideas) posted by slushpupie

Tue, 08 Jan 2008 17:41:23 -0600

Its best to support both. Some mail clients don't know how to do one or the other, some firewall admins like to keep ports to a minimum, others still like to block things that are not SSL, so regardless what the IMAP guys think, both is good. Its easy enough to do, too: (god, typing code in here sucks, please excuse all the errors)

config file format posted by sailfrog

Tue, 08 Jan 2008 17:29:00 -0600

I have gotten quite used to the convenience of using php for config files. Defining arrays, setting object properties, etc. However its far from user friendly. The config file parsing in Hastymail is pathetically fragile as I recall, which I want to avoid this time around. While structure (ala xml) is nice, I find that to be a pain to hand edit and in this case I don't see any significant benifits. We could do something like Squirrelmail for configuration, but that adds quite a bit of work to the process.Any suggestions?

STARTTLS for PHP5 then (IMAP ideas) posted by sailfrog

Tue, 08 Jan 2008 09:25:33 -0600

So we should see if we can use that to enable STARTTLS support for PHP5 I think. I seem to recall that the IMAP developers believe this is preferred way to go. Maybe thats changed since I was up on the IMAP discussions but I doubt it.

SSL/TLS Socket (IMAP ideas) posted by slushpupie

Tue, 08 Jan 2008 09:05:30 -0600

PHP5 has a "stream_socket_enable_crypto()" function that allows you to enable encryption on an existing socket, but PHP4 dosnt have anything like that.

Basics of the application framework posted by sailfrog

Sat, 05 Jan 2008 02:54:08 -0600

So I have been taking some time to review the framework and think about how best to alter it to make it work well for a webmail IMAP client instead of a mysql based website. There are not too many changes to the core of how it works but there will be a few. I thought it might be wise to start discussing how this beast works before any code is put into place.The classes that comprise framework all reside in a single file. Without the mysql bits and other junk we don't need it will be approximately 1200 lines. Some classes are built on others, some are "wrappers" the pull various bits into one place. There are multiple reasons for it's seemingly awkward design and "super clean abstracted OO" is not on that list. I would imagine an OO purist might scoff at my techniques, but I digress. All page requests go to index.php. It includes only the minimum PHP files at first, and here we check our configuration and include any other php files on as needed bases. It kicks off the two important objects, $user, and $pd. $user comprises the "backend" and $pd handles outputting the page.Part of the design of this code is to centralize functions/methods that do similar tasks, and to ease the job for the programmer to handle those tasks (and of course to separate presentation). When the $user object is started we check the status of our login, handle a login action, a logout action, setup/tear down a session, then process _POST data, then process _GET data. Logins are "special" in that they are handled by the core code, all other _POST data is handled by the form processing system after we determine if we are logged in or not.forms in this system must be registered in a separate file. This requires creating an array that has all the form field names and types, whether they are required or not, as well as a label for automatic notices. Each from definition in this file is keyed by the name of it's submit button (not it's value). So an example entry for a form might be like this:'flag_message' => array( 'message_id' => array('int', 1, 'Message ID'), 'mailbox' => array('string', 1, 'Mailbox'),), which would correspond to a form written like this:So what framework does is check for a non-empty _POST. If so then it includes the post processing PHP files then starts the system. The system looks at all the defined buttons in the registered list and checks to see if one exists in _POST. If so it goes through the defined fields and checks for the presence and correct type of any required for this form. If the form fails notices for the user are gathered and the POST data is made available to the presentation code in such a way as to make it trivial to repopulate the form while telling the user what they did incorrectly. If the form passes the requirements a method is called in a post function file, named form_action_. This method gets the form definition and the raw post data handed to it. These methods are where we then process any remaining error checking, do something with the submitted data, then set either error flags or completion notices for the presentation code.The _GET processing system is currently based on clean urls (like at the this site), but it won't take much to modify, and there are some non-clean url bits in place already. I plan on creating a similar system for _GET processing, including a type list as well as a "trigger system" that fires off a method. So for example we could require every url to have a page arg and it's value, assuming its defined in the list, would trigger a url_action_ method to run. The _GET processing runs after the _POST, and here we setup any data we need to pass onto the presentation side.Presentation is handled by yet another trigger system, this one hinging on a value I mysteriously call "dsp_page". This is set to "not_found" by default, and when we check the page arg on the url for a valid value, in each of the corresponding url_action functions we set dsp_page to whatever page we want to display (compose, mailbox, message, etc). So we set dsp_page to what we want to see, we grab any data from whatever source we need (imap, mysq, etc), then the url_action function exits, and the template system begins. All pages, except those short circuited somewhere along the line (such as outputting rss), call the main template. It in turn can call methods to drop in "chunks" of the page. In the primary content area of the page, the last trigger is run, and a method called print_ is run to populate that area.Whats nice about this system is lets say we want to add a compose page. First thing we do is define "compose" as a valid value for the "page" url arg. Then we take our browser there. It dies with a fatal error because there is no "url_action_compose" method. We create that and prep the page info we will need then set dsp_page to 'compose'. Refresh the page and we have a new error, no "print_compose" method. We add that and thats it, we have a new page in our application. It is also possible to call another template from the main template if we choose to, which can be handy when we have a significantly different page to render. url_action functions are grouped together in a file. form_action functions are also grouped together in there own file (and only even included if POST is not empty) and print_ functions are also grouped together in a file. I have used this arrangement for some large projects and with only a few modifications on occasion it has the very nice benefit of each file staying at a maintainable size.So hopefully some of that makes sense to somebody other than me. Lord knows I should not be writing anything to anybody anywhere at 3 in the morning.

Email sent (AJAX features) posted by sailfrog

Sat, 05 Jan 2008 02:03:23 -0600

I sent off an Email to the developers seeing how they felt about it. I offered to do just as you suggested, as well as clearly state the licensing on our site, include any docs and credits in the code, etc.

Re: BSD license (AJAX features) posted by slushpupie

Fri, 04 Jan 2008 14:46:48 -0600

No, you cant relicense it. But there is nothing saying you cant distribute a project with multiple licenses... just keep the bits separate.

Copyright Holder (General Thoughts) posted by slushpupie

Fri, 04 Jan 2008 14:43:43 -0600

As the copyright holder (you), you can change the license at any time, make whatever changes you want to it since it is your work. The licensing only comes into play when you let someone else have rights. As long as you did not give (sole) ownership of your code to any of the clients, the code is (also) yours. So if you take a part of it and release it as GPL, that is your doing and it works out fine.

More info on the licensing issues (AJAX features) posted by sailfrog

Fri, 04 Jan 2008 10:45:43 -0600

I just took a quick look at the Sajax site (which is what my ajax subsystem is a derivative of) and it is covered by the BSD license. From there site:"it is open source and licensed under the BSD license. This means you can do basically whatever you want with it, even charge people for it."I have a sinking feeling that "do anything you want with it" might not include modifying it and redistributing it under the GPL