Re: Bug #676: nntp module based on imap module. (fwd)

Gerrit, I am not sure if you are on the php-dev list or not, so I have included the entire message from Mark at the bottom of this one. I think Mark has the right idea here. I would return the information in a 2-dimensional array. I see no point in an object here. The structure of the array would be: [UID] [UID of Parent] Where UID is the unique message id, or perhaps optionally the sequential message number. To be consistent, make the default the sequential message number and add an optional flags parameter that can be set to FT_UID to tell the function to use UID's instead. The function would look like this: array imap_thread(int imap_stream, string mailbox [, int flags]) The returned array would be ordered such that it might look something like this: 1 0 2 1 4 2 3 1 5 0 6 0 7 6 8 6 9 8 10 9 This would correspond to 10 messages that were threaded like this: +Message 1 | +-- Message 2 | | | +-- Message 4 | +-- Message 3 +Message 5 +Message 6 | +-- Message 7 | +-- Message 8 | +-- Message 9 | +-- Message 10 Given the simple array at the top, this tree is easy to construct. Mark had suggested also returning the number of references to each one. I am not sure how this would be useful though. On Sun, 23 Aug 1998, Mark Musone wrote: > Hi.. > > > I agree to use a single module for imap and nntp. I will work on the > > threaded sort and let you know how it goes. My problem at the moment is the > > desciding how to format the return data. > > I know i've seen a threaded sort already in the imap library (i believe it's > undocumented) > i'll look for it tomorrow.. > > > > > I am not sure whether to sort a set of headers provided in an arrya to the > > routine or to provide a structure containing all the headers in a threaded > > structure. The resultant structure I use at the moment in php script is an > > array of objects where one of the objects attributes is an array of objects. > > > > I have a feeling that such a comeplex structure would be unusable for the > > run of the mill script writers and would require some support functions. This > > leads me to the idea of defining a php tree strucure with routines like the > > array structure that perform the data insertion and traversing operations. > > A tree class could look something like > > class tree { > > var (object) this_data; # data for this location. > > var (object) subtree[]; # array of tree objects . > > var (object) leftbranch; # left and right brach poiters for creating a > > binary tree. > > var (object) rightbranch; # could be done by using subtree[0] for left > > and subtree[1] for right. > > } > > > > A problem I face with the threaded sort is that the messages that define the > > whole depth may not be within the range of the headers supplied or no longer > > available from the server. This means that a tree that defines the whole > > threaded structure may contain entries for message that either should not or > > cannot be retrieved. The message number header attribute could be used with > > invalid values to indicate that a location is a placeholder. > > > > > Ummm...wow! highly complex!! > > My first question would be to figure out how/why people would need this > (complex) information for a web application... > > Given the fact that this is all stateless, Could a solution be as simple as the > thread function simply returning an array of message numbers, essentially in > "thread sorted" order? > > When you'd display the list of messages, you'd normally be having a simple > link to that article's number anyway, so any real-time manipulation of threads may > be unecessary, and actually improbable. > > So maybe a better approach might be a set of functions to return different thread parts, > something like > > thread_sort - returns an array of message numbers in thread order. > thread_parent - returns the message number of the parent thread > thread_refs - returns the number of references to the given thread > > > Thoughts, Comments? > > Mark > -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net