Re: NFS: Wrapping up on Big question for 9Val thread
Hello MAU, On Thursday, September 9, 2004 at 11:58:37 PM you [M] wrote (at least in part): [very short NFS description] M Hey! You look like a good candidate to write TB's HELP. ;-) Hey, you look like you want the shortest help ever seen being delivered ;-) I fear the help would end up quite too short if I were going to write it ;) Unless something like this is implemented I don't see good reasons to provide structural elements like mentioned GOTO :-) M I don't feel any strong need for them. I was asking and you answered. :) So you're a dazzler; some days ago you said you're stubborn :P :gdr: -- Regards Peter Palmreuther (The Bat! v3.0.0.11 on Windows XP 5.1 Build 2600 Service Pack 1) I have a photographic memory but the lens cover is glued on. Current beta is 3.00.11 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
Re: NFS: Wrapping up on Big question for 9Val thread
Hello MAU, On Thursday, September 9, 2004 at 4:37:13 PM you [M] wrote (at least in part): M 4.- Actions possible before and after a Move. Agreed to the compromise, as this is what I'd call the natural way :-) M Yes, but the natural way should be clearly explained to the users just M in case. Well, OK. That's done quite fast and easy: A filter treats a message in top-down order of instructions. Everything is performed and applied on 'the message' where ever it might be currently located. A 'copy' actions creates an anonymous duplicate in the desired destination, which is not available for further actions. Everything done to a message after a 'delete' action is treated as 'not done anyway', because there is nothing left that could actions be performed on. All in all this description should cover most of what's the essence ;-) Or even shorter: Don't care for where the message is, just deal with it. A 'copy' action does not create a new handle to deal with, but only a duplicate manifestation of the message with all it's states. A 'delete' action disables you to do anything with this message from point of deletion downwards. M Since the filter have names, what about including unstructured 'GO M TO filter' as a possible action? *woaaa* That'll open a can of worms :-) M I knew it! I knew it! ;-) But they were so useful! Not allowing them in M modern languages is a way of, as 9Val would say, spying on the M programmers ;-) Name it as you like, unstructured is the key. ;-) Modern languages include GOTO (or similar) construct, but using them is a matter that should be thought about twice. As we don't have complex syntax abilities for avoiding loops I'd say it's a bad idea to implement GOTO-like possibilities. You simply can't set a variable been here which can be checked second time a filter is entered, and therefore you're extremely limited in abilities to break a filter loop, created by GOTO. Implementing GOTO in NFS would IMHO require a quite complex filtering syntax near to a filtering programming language. This would require implementing something like 'procmail' or 'maildrop' with all it's control structures and abilities. Unless something like this is implemented I don't see good reasons to provide structural elements like mentioned GOTO :-) -- Regards Peter Palmreuther (The Bat! v3.0.0.8 on Windows XP 5.1 Build 2600 Service Pack 1) Sometimes a cigar is just a cigar. - Sigmund Freud Current beta is 3.00.08 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
Re: NFS: Wrapping up on Big question for 9Val thread
Hello Peter, Or even shorter: Don't care for where the message is, just deal with it. A 'copy' action does not create a new handle to deal with, but only a duplicate manifestation of the message with all it's states. A 'delete' action disables you to do anything with this message from point of deletion downwards. Hey! You look like a good candidate to write TB's HELP. ;-) Unless something like this is implemented I don't see good reasons to provide structural elements like mentioned GOTO :-) I don't feel any strong need for them. I was asking and you answered. :) -- Best regards, Miguel A. Urech (El Escorial - Spain) Using The Bat! v3.0.0.8 Current beta is 3.00.11 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
Re: NFS: Wrapping up on Big question for 9Val thread
Hello Peter, I know. But I'd like to see NFS flawlessly and proven reliable before NNFS gets into it's first Alpha state :-) Me too :) -- Best regards, Miguel A. Urech (El Escorial - Spain) Using The Bat! v3.0.0.8 Current beta is 3.00.11 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
Re: NFS: Wrapping up on Big question for 9Val thread
On Wednesday, September 8, 2004, 18:06, 9Val wrote: M With or without modifications done by a previous filter? With modifications - remember, object is the same Now I think it is even more important to not let the NFS move a parked message, whether it is originally parked or parked by the filter itself. If you want a moved message parked, move it first, then park it. I can well imagine the use for filters parking certain messages before passing them on to other filters, mostly to stop a subsequent filter from moving the message. Can we agree that a filter should not be able to move a message which has been parked earlier in _the same_ filtering session? If so, it would be confusing if the same logic didn't apply to message manipulation within _one filter_. If a message is parked, it shouldn't be able to move, regardless of whether it was parked before processed by the filter or by the filter itself. If I want to move and park a message, I should be forced to move it first and then park it. I see no downsides of such an implementation, but letting filters move parked messages during some conditions but not during other - well, that would be confusing. I think MAU and Peter (and others) have done a terrific job analysing the ups and downs of different implementation strategies, I don't have much to add except the above. -- Regards, Marcus Ohlström Using The Bat! v3.0.0.8 on Windows 2000 5.0 Build 2195 Service Pack 4 PGP Public Key at http://www.canit.se/~marcus/pgp.asc Current beta is 3.00.08 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
