also, it appears that the date format as posted to ibbslastcall-data is currently determined by the locale, so we have a mix of strftime of %m/%d/%y and %d/%m/%y in the output. for flexibility, perhaps, posting
to the data stream should conform with ISO 8601 (i.e. %Y-%m-%d) and then reformatting the output would be based on the BBS locale. this would entail mangling the incoming data for the date, which would be a few
lines of code more, but it would allow for consistent presentation of
the data. :)
a) email_from == "ibbslastcall"
b) email_subject == "ibbslastcall-data"
c) and subj != mci2str("BN")
non-"ibbslastcall" programs to send data to ibbslastcall? this will
allow other apps to participate in the ibbs lastcaller data stream.
also, it appears that the date format as posted to ibbslastcall-data is currently determined by the locale, so we have a mix of strftime of %m/%d/%y and %d/%m/%y in the output. for flexibility, perhaps, posting
to the data stream should conform with ISO 8601 (i.e. %Y-%m-%d) and then reformatting the output would be based on the BBS locale. this would entail mangling the incoming data for the date, which would be a few
lines of code more, but it would allow for consistent presentation of
the data. :)
a) email_from == "ibbslastcall"
b) email_subject == "ibbslastcall-data"
c) and subj != mci2str("BN")
non-"ibbslastcall" programs to send data to ibbslastcall? this will allow other apps to participate in the ibbs lastcaller data stream.
Any program/script that will send a msg with the From field as "ibbslastcall x>can participate. Its there, just for the other program (xq-ilc_get) to know x>that this is a packet for the lastcaller script... Any script that "honors" x>this rule, can be part of the data stream. Did i understand wrong your x>question?
When i created the script, for sure i didn't thought of that. Because no one x>ever complained i didn't fix it :) but i guess its time now :) As a solution x>propose to write the date in the packet as a number and not as a date format x>string. For example we could use a value of Unix timedate or DOS. The x>receiving system can convert that number to the local timedate format. I am x>not sure if this is possible for all systems. For example MPL supports DOS x>date format but not UNIX, perhaps a different BBS system doesn't support one x>of them or even both.
Even so, there will always be the problem with the time zones and because i x>using an MPL for the send script, perhaps is not possible to fix it, with MP x>May be its time to learn more on Python and convert it to MPY. Any help will x>be appreciated :)
i was suggesting to relax the requirement for the From field, so that other ibbslastcaller implementations (for non-Mystic BBSes) can use a different name for posting, but still have the subject of ibbslastcall-data. it can help identify which implementation might have possible bugs if any. for example, if my implementation on wwiv posts
data in the wrong format, but it still identifies itself as
ibbslastcall, cursory investigation won't reveal that the problem was in my implementation.
i tested using a different From field to make it easier to identify that the implementation was not xq-ilc_send.mps. of course, xq-ilc_get.mpy didn't accept the data from "wwivibbslastcall" even if it conformed with subject and rot47 encoded data format.
relaxing the from field requirement will allow other ibbslastcall-data programs or mods to be written. the data-interchange remains the same,
but the implementations at the different end-points can be different, allowing for other and more variation.
don't get me wrong. i'm not complaining. this is part of the fun in BBSing!
don't get me wrong. i'm not complaining. this is part of the fun in BBSing!
Sure :) I hope i didn't say something wrong. I like your ideas and for sure x>want to correct that "date format" problem. :)
Do you think as an idea to place a date value as unix timedate? or keep it a x>a string?
Sysop: | echicken |
---|---|
Location: | Toronto, Ontario |
Users: | 2,224 |
Nodes: | 6 (0 / 6) |
Uptime: | 210:26:38 |
Calls: | 14,142 |
Files: | 295 |
Messages: | 551,094 |