hi xqtr,

i read through xq-ilc_get.mpy and noticed that the current code requires:

a) email_from == "ibbslastcall"
b) email_subject == "ibbslastcall-data"
c) and subj != mci2str("BN")

would it be possible to relax the scope of search to allow 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. :)

best,

-=<(xenos)>=-
A .-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-.
/*\ | /\liens' /\lcove! WWIV on Linux - Taguig, Metro Manila, Philippines |
/ v \`-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=[ WWIV Reg. #30282 ]-=-=-=-=-=-=-=-'

--- WWIV 5.3.0.development
* Origin: /\lien's /\lcove! WWIV BBS - Taguig City, Philippines (21:4/147)

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. :)

+1 for this idea!!

I have often been thrown off my the inconsistent dates coming in from ibbslastcall... I was getting around to mentioning it but never found the time while i had it in my head... thanks for bringing it up, Xenos.

---
|14Best regards,
|11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N

|07�� |08[|10eml|08] |[email protected] |07�� |08[|10web|08] |15www.erb.pw |07��Ŀ |07�� |08[|09fsx|08] |1521:1/158 |07�� |08[|11tqw|08] |151337:1/101 |07���� |07�� |08[|12rtn|08] |1580:774/81 |07�� |08[|14fdn|08] |152:250/5 |07����

--- Mystic BBS v1.12 A43 2019/02/23 (Linux/64)
* Origin: The Quantum Wormhole, Ramsgate, UK. bbs.erb.pw (21:1/158)

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" can participate. Its there, just for the other program (xq-ilc_get) to know that this is a packet for the lastcaller script... Any script that "honors" this rule, can be part of the data stream. Did i understand wrong your question?

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. :)

When i created the script, for sure i didn't thought of that. Because no one ever complained i didn't fix it :) but i guess its time now :) As a solution i propose to write the date in the packet as a number and not as a date formated string. For example we could use a value of Unix timedate or DOS. The
receiving system can convert that number to the local timedate format. I am
not sure if this is possible for all systems. For example MPL supports DOS
date format but not UNIX, perhaps a different BBS system doesn't support one
of them or even both.

Even so, there will always be the problem with the time zones and because i am using an MPL for the send script, perhaps is not possible to fix it, with MPL. May be its time to learn more on Python and convert it to MPY. Any help will
be appreciated :)

.----- --- -- -
| Another Droid BBS
: Telnet : andr01d.zapto.org:9999 [UTC 11:00 - 20:00]
. Contact : [email protected]

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: Another Droid BBS # andr01d.zapto.org:9999 (21:1/111)

RE: Re: ibbslastcall
BY: xqtr (21:1/111)

On Saturday, March 02, 2019 at 01:38 PM, Xqtr (21:1/111) wrote:

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?

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.

it is still just a suggestion, and i'll abide by your decision.

more in another follow-up message.

-=<(xenos)>=-
A .-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-.
/*\ | /\liens' /\lcove! WWIV on Linux - Taguig, Metro Manila, Philippines |
/ v \`-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=[ WWIV Reg. #30282 ]-=-=-=-=-=-=-=-'

--- WWIV 5.3.0.development
* Origin: /\lien's /\lcove! WWIV BBS - Taguig City, Philippines (21:4/147)

RE: Re: ibbslastcall
BY: xqtr (21:1/111)

On Saturday, March 02, 2019 at 01:38 PM, Xqtr (21:1/111) wrote:

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 :)

don't get me wrong. i'm not complaining. this is part of the fun in BBSing!

now, yes, it'll be good to learn Python. i hacked together something for my WWIV to display interbbs last caller data. at the moment it's very rough, but it works! :) i back-ported it to my set-up on aliens.free.net.ph if you'd like to see it. it isn't as refined as yours, but it does the job.

-=<(xenos)>=-
A .-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-.
/*\ | /\liens' /\lcove! WWIV on Linux - Taguig, Metro Manila, Philippines |
/ v \`-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=[ WWIV Reg. #30282 ]-=-=-=-=-=-=-=-'

--- WWIV 5.3.0.development
* Origin: /\lien's /\lcove! WWIV BBS - Taguig City, Philippines (21:4/147)

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.

Makes sense :)

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.

Yeap... the mpy script checks for the Sender and the Subject. Its easy to make it check only the Subject and do what you propose. I will do it in the next release, after fixing the "date" thing :) If you want to make your tests
easier change this line:

if msghdr["from"] == email_from and msghdr["to"] == email_to and
msghdr["subj"] != mci2str("BN"):

to:

if msghdr["to"] == email_to and msghdr["subj"] != mci2str("BN"):

You are removing the "from" field from the if statement. When we confirm all changes to the script, i will apply them to a new version.

.----- --- -- -
| Another Droid BBS
: Telnet : andr01d.zapto.org:9999 [UTC 11:00 - 20:00]
. Contact : [email protected]

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: Another Droid BBS # andr01d.zapto.org:9999 (21:1/111)

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 i want to correct that "date format" problem. :)

Do you think as an idea to place a date value as unix timedate? or keep it as
a string?

.----- --- -- -
| Another Droid BBS
: Telnet : andr01d.zapto.org:9999 [UTC 11:00 - 20:00]
. Contact : [email protected]

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: Another Droid BBS # andr01d.zapto.org:9999 (21:1/111)

RE: Re: ibbslastcall
BY: xqtr (21:1/111)

On Sunday, March 03, 2019 at 01:46 PM, Xqtr (21:1/111) wrote:

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?

Off the top of my head, if the time/date strings were replaced with a single value like seconds since the epoch (1970-01-01 UTC), the ibbs last caller send code would unify the date and time lines into a single line/field. The ibbs last caller get code would then decode the single line/field from the number to the time and date format for the locale of the BBS that is displaying the list. Since seconds since the epoch is based on UTC, the ilc get code would be responsible for converting the number to the BBS's locale format.

In Unix, it would be like:

To encode:

$ date +"%s"

To decode:

$ date --date='@2147483647'

I'll post the equivalent code in C and Python when I wake up. I'm off to bed.

Ciao!

-=<(xenos)>=-
A .-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-.
/*\ | /\liens' /\lcove! WWIV on Linux - Taguig, Metro Manila, Philippines |
/ v \`-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=[ WWIV Reg. #30282 ]-=-=-=-=-=-=-=-'

--- WWIV 5.3.0.development
* Origin: /\lien's /\lcove! WWIV BBS - Taguig City, Philippines (21:4/147)