This is an initial attempt to describe folder namespaces in mvmf utilities. When your MFL script writes a mail message to a folder, that folder must be located in a folder namespace. A namespace is selected by the first part of the folder name. Perhaps an example is best before going further. Let's say you have a sieve statement: fileinto "FOLDERS/work"; In this example, we'll say that the namespace is called "FOLDERS/" and that the statement puts the message into a folder called "work" within that namespace. And that's the gist of it. The first part of the folder name that you use will match a namespace name, and the rest of the folder name has some meaning within that namespace. When you write a script to file a message into a folder, you have to know what namespaces are available, and perhaps a little bit about them. One idiosyncracy (er, niffty aspect) of mvmf namespaces is that the longest namespace name wins. One can imagine mvmf namespaces being created to match a common sieve and IMAP model: that a name "INBOX" refers to your incoming mail folder, whereas a name "INBOX.something" refers to a subfolder called "something". "INBOX" and "INBOX." can be two different namespaces with very different characteristics. For example, "INBOX" could refer to an mbox format mailbox at '/var/mail/user', whereas "INBOX." could map to a Maildir++ hierarchy within the user's home directory. Or if you are a UNIX shell user, you might create two parallel namespaces that refer to the same directory, but which have different default storage types. (e.g. "MAILDIR/" and "MBOX/"). (Note that if a folder already exists, mvmf will attempt to use it via whatever type it is, regardless of the default type of the namespace.) A namespace prefix can be empty, as well. If you define a namespace with an empty prefix, it will be the namespace of last resort; i.e., it will match anything not matched by a namespace with a longer prefix. In most environments it's anticipated that an administrator has defined the namespaces you can use. The administrator will make these known to you. If, on the other hand, YOU are the administrator, or if you are running an mvmf utility standalone, or if you simply want to create your own namespaces, you need to know some details of creating and parameterizing namespaces. To create (and fully understand) namespaces, you need to know how they are parameterized. Don't be daunted by the length of this text, it's really fairly straightforward. In mvmf, a message folder has a specific storage type. Specific storage types include "mbox" and "maildir". Underneath the specific storage type is a general storage type. You will never touch this directly, but it's important to know that some of the specific storage types' attributes are really associated with the general type. The specific types "mbox" and "maildir" are of the general storage type "file" -- and files have certain things that you can say about them. Each namespace is associated with a specific storage type. When you create a namespace, it gets a copy of all of the attributes that have been defined for that specific storage type at that time. You can then further parameterize a namespace with any attribute that can be associated with that specific storage type (which, in turn, can have any attribute that its general storage type supports). Further, namespaces themselves may have attributes that relate to namespaces only, and not to any particular storage type. With that, when you are defining how you want your folders to work, you'll do these general things: - assign attributes to specific storage types. e.g. you might want to specify how locking of mbox types works, before deriving any namespaces from it. - create namespaces relating to specific storage types, and give them additional attributes. There are two types of attributes: integers and strings. Each attribute has a name and a value. ==================== General file type attributes These attributes can be associated with anything that is related to the general storage type "file" . This includes the "mbox" and "maildir" specific types, and any namespace associated with them. "layout" (string) -- how the names are laid out within the namespace's directory path. A layout type of "fs" (or "filesystem") simply maps the folder name's tail (the part after the namespace prefix has been removed) to a file within the namespace's path. A layout type of "maildir++" is similar, except that it adds a leading "." character to the filename, and replaces all "/" characters with "." . See also the namespace "tailhook" hack that provides a way for you to edit the tail. "locking" (string) -- what sort of locking to apply. This is a comma-separated list of locking specification, which are applied in the order given. Each specification is simply the name of the locking type to use: choose from the set {dotlock, fcntl, flock, lockf}. Note that your system might not support all of them; any type not supported is ignored. If there are no recognized lock types in the attribute you set, no locking is done! "path" (string) -- the filesystem path for that storage. ==================== "mbox" specific type attributes (mbox-specific attributes are yet to be defined) ==================== "maildir" specific type attributes (maildir-specific attributes are yet to be defined) ==================== Namespace attributes Namespaces themselves may have additional attributes. These, like mbox and maildir, are yet to be defined. ==================== Namespace tailhook There is also a "tailhook" capability associated with namespaces. This provides you a way to alter the tail part of the folder name before it's used in generating the full folder name. The tailhook is an MFL function that you write that massages the tail string. Remember that the folder name is viewed as a namespace prefix followed by a folder tail. When you provide a tailhook, the tail portion is passed to that hook, which must return a new string that represents the tail string you really want. For example, let's say (as in the example below) you have a namespace "MBOX/" that might refer to a directory "Mail/" in users' home directory. When writing to "MBOX/MINE" the default action would be to write to "Mail/MINE". You could define a tailhook "mail_tail" to add a prefix and to make the foldername lowercase: string mail_tail( string tail ) { return ( (string)"xx-" + $str_lower(tail) ); }; (Note well: this is a hack that is done this way because MFL does not yet have lambda expressions. If lambda expressions come to pass, this tailhook association might be phased out.) ==================== MFL functions use the "$msst_" and "$msns_" families of built-in functions to assign attributes and to define namespaces. Please refer to the built-in-function documentation (e.g. on the mvmf website) for specifics. ==================== Examples This sequence will define an INBOX namespace that points to the incoming mbox in /var/mail, an "INBOX." namespace that refers to a Maildir in the users' home directory, and two namespaces MAILDIR/ and MBOX/ which refer the user's "Mail" subdirectory (this is fairly unsophisticated; real code might have more checks). For the MAILDIR and MBOX namespaces, a "mail_tail" tailhook is associated-- note that the mail_tail function must be defined before the namespace is used. Here, we'll assume that it's defined as in the example above. // First parameterize the way we want specific types to work by default $msst_attr_string_set( "mbox", "locking", "dotlock, flock" ); $msst_attr_string_set( "mbox", "layout", "fs" ); $msst_attr_string_set( "maildir", "layout", "maildir++" ); // Create the INBOX $msns_define( "INBOX", "mbox" ); $msns_attr_string_set( "INBOX", "path", (string)"/var/mail/" + $env_variable( "USER" ) ); // Create the "INBOX." namespace for default folder storage // inside ~/Maildir $msns_define( "INBOX.", "maildir" ); $msns_attr_string_set( "INBOX.", "path", (*$env_homedir()) + "/Maildir" ); // Create the MAILDIR and MBOX namespaces which are different views // into the same directory. Note the override of the layout for // the maildir view. $msns_define( "MAILDIR/", "maildir" ); $msns_attr_string_set( "MAILDIR/", "path", (*$env_homedir()) + "/Mail" ); $msns_attr_string_set( "MAILDIR/", "layout", "fs" ); $msns_tailhook( "MAILDIR/", "mail_tail" ); $msns_define( "MBOX/", "mbox" ); $msns_attr_string_set( "MBOX/", "path", (*$env_homedir()) + "/Mail" ); $msns_attr_string_set( "MBOX/", "layout", "fs" ); $msns_tailhook( "MBOX/", "mail_tail" ); Now one can reference the ~/Maildir subfolder xx as "INBOX.xx" . When a script writes to "MBOX/foo" (that doesn't previously exist), the file ~/Mail/xx-foo will be created as an mbox; writing to a new "MAILDIR/foo" will create ~/Mail/xx-foo as a maildir. (The "xx-" is added by the tailhook). -mm- 20061111/20070108 mem@geezer.org or mem@mvmf.org