On 12/09/17, Nugax said the following...

Is there a way to auto hatch a file manually put via automation into a networked file area, think auto created nodelist generated and having Mystic hatch it for the downlinks

i made an mpl that would write a echomail.out so when you generate it it hatches. i added it to sysop menu.

|08 .|05ú|13ù|15Dr|07e|08am Ma|07st|15er|13ù|05ú|08.
|08 øù|05ú|13ùø |13øù|05ú|08ùø
|11 DoRE|03!|11ACiDiC|03!|11Demonic |08[|15dreamland|09.|15darktech|09.|15org|08]

--- Mystic BBS v1.12 A36 2017/12/03 (Windows/64)
* Origin: |08--[|15!|07dreamland BBS dreamland.darktech.org (21:1/163)

On 12/09/17, Nugax pondered and said...

Is there a way to auto hatch a file manually put via automation into a networked file area, think auto created nodelist generated and having Mystic hatch it for the downlinks

I you generate a .TIC file with the incoming file then Mystic would toss and hatch it to connected node. But asides that I can't think of any way of doing it. I'm fairly sure I have asked in a wish list some time ago if a MUTIL hatching stanza could be added so files could be hatched in the same was a
text files can be posted to echo areas. And I'm fairly sure g00r00 was open
to such an idea and it's now on his massive TODO list :) I'd say just watch this space and something may come of it in time.. but for now my first suggestion is the way I suggest you do it.

--- Mystic BBS v1.12 A37 2017/12/07 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

the same was a text files can be posted to echo areas. And I'm fairly
sure g00r00 was open to such an idea and it's now on his massive TODO
list :) I'd say just watch this space and something may come of it in time.. but for now my first suggestion is the way I suggest you do it.

Yep this is something that I needed to do. I can't remember what the hold up was, it was either because of the echomail groups or because we couldn't figure how it needed to work.

One of the restrictions is that the file has to be in the BBS filebases for
it to be hatched, because that is how the hatching details are tracked...

Mystic needs a way to know BBS-related data about the file so that if you compile a list of files you want hatched automatically (whenever they're updated), Mystic can look to see if each particular file was updated and whether or not it has been hatched yet.

Because of that the process would probably be for your file to get copied into the proper file base, then MUTIL would catch that it was updated via mass upload and flag it as changed. MUTIL would then see it has been updated and hatch it based on its configuration of auto-hatched files.

We'll probably end up with something like an MUTIL stanza that has a list of file references by file base ID and filename:

file=3;nodelist.zip
file=12;mys112a*.*

I have been slowly working on a way to kick off MUTIL stanzas from command
line too, so that will give us that option as well.

Anyway, any thoughts or complaints about this idea?

--- Mystic BBS v1.12 A37 2017/12/09 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 12/09/17, g00r00 pondered and said...

One of the restrictions is that the file has to be in the BBS filebases for it to be hatched, because that is how the hatching details are tracked...
Mystic needs a way to know BBS-related data about the file so that if you compile a list of files you want hatched automatically (whenever they're updated), Mystic can look to see if each particular file was updated and whether or not it has been hatched yet.

Yep I recall discussing this now..it's all about how to automate things in a way that enables all of those boxes to be ticked.

Because of that the process would probably be for your file to get
copied into the proper file base, then MUTIL would catch that it was updated via mass upload and flag it as changed. MUTIL would then see it has been updated and hatch it based on its configuration of auto-hatched files.

This is the bit I need to better understand and offer some feedback on. I can see a couple of scenarios.

1) Sysop points to assorted files in a folder and says to MUTIL do a
special mass upload of the files with a mask of bre*.* to file index area 1,
do the same for files called impure*.* and upload to file index area 2 etc.. *and* hatch anything uploaded immediately thereafter. I say 'special' mass upload as I think this process should be (although similar to the mass upload stanza) separate from it and embedded in to the hatch stanza.

So in this scenario the BBS is only 'learning' of the new files as they are being uploaded and added to file bases.. there is no compare old with new logic.

We'll probably end up with something like an MUTIL stanza that has a
list of file references by file base ID and filename:

file=3;nodelist.zip
file=12;mys112a*.*

I like this .. and the logic works for my above scenario and for the other scenario we're discussing.. which is..

2) Files with a regular name convention are generated e.g. a nodelist file
like fsxnet.123 and we want Mystic to be able to look at an output directory of the nodelist generation tool e.g. MakeNL and run an 'import the file into base X, apply old vs new comparison logic and if 'newer' then hatch out' process
to those files.


Related thoughts

The import and hatch process should not be case sensitive if a file is called fsxnet.zip or FSXNET.ZIP then I think it should be treated the same.

If you work on something like scenario 1 then consider allowing a recursive directory search option to allow Mystic to import and hatch files contained
in children directories. But in saying that perhaps it's better to force a sysop to state the directories else risk crazy bad things happening! :)

Should the MUTIL hatch stanza options also include similar options as per
mass upload stanza?

--- Mystic BBS v1.12 A37 2017/12/07 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

Avon,

list :) I'd say just watch this space and something may come of it in time.. but for now my first suggestion is the way I suggest you do it.

We must be patient. All coders know it takes an enormous amount of time to
get things to work as they should and so many demands on improvments. Let us just see what develops and keep the ball rolling with new ideas and suggestions.

-- cr1mson

--- Mystic BBS v1.12 A36 2017/12/03 (Windows/32)
* Origin: Raiders Inc BBS -- vintagebbsing.com (21:1/154)

1) Sysop points to assorted files in a folder and says to MUTIL do a special mass upload of the files with a mask of bre*.* to file index
area 1, do the same for files called impure*.* and upload to file index area 2 etc.. *and* hatch anything uploaded immediately thereafter. I say

There are two ways I think automated hatching can/will work:

The first is MUTIL could have an "auto hatch" section where you list files and their file bases that you want to hatch whenever they're updated. Say base 12 file "nodelist.zip". To hatch it you'd just have your batch file that generates the nodelist copy nodelist.zip into it's filebase's directory and thats it...

MUTIL's massupload will find that nodelist.zip changed, and update Mystic's filebases. MUTIL's auto hatch will then see the changed file, check if its been hatched, and hatch it if it hasn't.

The alternative to that would be a command line hatch where you might say "mutil -Hatch 12;filename.zip" and it will put the file into file base 12's directory for you, then update Mystic's file listings, and finally queue it for hatching.

They both do the same thing at the end of the day. The difference is the command line will let you hatch a single file anywhere and it'll move it for you whereas the MUTIL approach is more powerful in the long run.

For example: I have MUTIL AutoHatch configured to hatch "mys112*.*" from base 15 which is "Mystic Alphas" file base. My build script creates the new archives and drops them in "c:\mystic\files\mysticalphas". Thats all it
takes and Mystic does the rest.

MUTIL MassUpload sees all these new files and updates the file database.
MUTIL AutoHatch look at mys112*.* and sees they've changed and hatches them.

If we choose strictly the command line option then the question is, where
does that command line go? MIS? FIDOPOLL? MUTIL? MYSTIC?

So in this scenario the BBS is only 'learning' of the new files as they are being uploaded and added to file bases.. there is no compare old
with new logic.

I think the above answered your question, but massupload doesn't just upload files, it will check their file information too and detect change.

--- Mystic BBS v1.12 A37 2017/12/09 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 12/10/17, g00r00 pondered and said...

There are two ways I think automated hatching can/will work:

The first is MUTIL could have an "auto hatch" section where you list
files and their file bases that you want to hatch whenever they're updated. Say base 12 file "nodelist.zip". To hatch it you'd just have your batch file that generates the nodelist copy nodelist.zip into it's filebase's directory and thats it...

Sounds good to me. And this would also allow for wildcard notation also so as to pick up variations on a file name? Or would this require a fixed filename
to work?

MUTIL's massupload will find that nodelist.zip changed, and update Mystic's filebases. MUTIL's auto hatch will then see the changed file, check if its been hatched, and hatch it if it hasn't.

What you describe above, would this all occur as part of running the 'auto hatch' stanza? When you talk of massupload I'm left wondering if that has to
be run as well along with the 'auto hatch' stanza? I kind of hope not and
that this functionality is all baked in to the once MUTIL function.

The alternative to that would be a command line hatch where you might say "mutil -Hatch 12;filename.zip" and it will put the file into file base 12's directory for you, then update Mystic's file listings, and finally queue it for hatching.

Yep that's a good option to have as well as the first.

They both do the same thing at the end of the day. The difference is the command line will let you hatch a single file anywhere and it'll move it for you whereas the MUTIL approach is more powerful in the long run.

I would give folks the option of both so as to not limit their options. You never know how creative folks can be so best to let them have those choices / tools.

For example: I have MUTIL AutoHatch configured to hatch "mys112*.*" from base 15 which is "Mystic Alphas" file base. My build script creates the new archives and drops them in "c:\mystic\files\mysticalphas". Thats
all it takes and Mystic does the rest.

MUTIL MassUpload sees all these new files and updates the file database. MUTIL AutoHatch look at mys112*.* and sees they've changed and hatches them.

I think this example might answer my earlier question, so you are talking of running two MUTIL functions to make this all work - right?

If we choose strictly the command line option then the question is, where does that command line go? MIS? FIDOPOLL? MUTIL? MYSTIC?

The answer depends, it depends on what you're looking to do in the long run.
I understand in the end you seek to roll all things in to one binary - right? Although that may be some ways off and there's no urgency anyways :) MUTIL would not be a good idea only in that everyone is used to calling it with an .ini to work so adding a command switch seems strange and may confuse some perhaps?

I tend to think MYSTIC is the way forward... as I can see how you could end
up with

MYSTIC SERVER
MYSTIC HATCH
MYSTIC -CFG
MYSTIC MAILIN.INI

Not 100% sure about all of the above, this will take some thinking as it
needs to be clear and consistent syntax for all aspects of the Mystic ecosystem... I'll keep pondering.

In the short terms the answer probably is - where you can best rest the code will dictate the binary to use.

So in this scenario the BBS is only 'learning' of the new files as th are being uploaded and added to file bases.. there is no compare old with new logic.

I think the above answered your question, but massupload doesn't just upload files, it will check their file information too and detect change.

As it's getting late here my brain is now a bit wooly... so will wait to test something then offer more - but thanks (as always) for the full considered replies.

Best, Paul

--- Mystic BBS v1.12 A37 2017/12/09 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

Avon wrote to Nugax <=-

On 12/09/17, Nugax pondered and said...

Is there a way to auto hatch a file manually put via automation into a networked file area, think auto created nodelist generated and having Mystic hatch it for the downlinks

I you generate a .TIC file with the incoming file then Mystic would
toss and hatch it to connected node. But asides that I can't think of
any way of doing it. I'm fairly sure I have asked in a wish list some
time ago if a MUTIL hatching stanza could be added so files could be hatched in the same was a text files can be posted to echo areas. And
I'm fairly sure g00r00 was open to such an idea and it's now on his massive TODO list :) I'd say just watch this space and something may
come of it in time.. but for now my first suggestion is the way I
suggest you do it.

I was looking at scripting this with my "hatch" scripts, but never got around to it. I found it relatively straightforward to generate the .TIC (even with CRC), and the process should be easily automated. Just never got around to doing it. Suppose I should, though my challenge was I generate the nodelist here on the Windows box and hatching occurs on the Pi running the BBS, so I'm stuck with a manual step. :( And that's a major issue for me. :(

Maybe I need to move nodelist maintenance to the Pi, then I can have a weekly event that hatches out the nodelist into the relevant file echo on VKRadio. :)

So, yes, it's currently doable, though it would be nice to be able to do it with mutil in the future.


... One good turn gets most of the blanket.
___ MultiMail/Win32 v0.49

--- Mystic BBS/QWK v1.12 A36 2017/12/04 (Raspberry Pi/32)
* Origin: The Bridge - bridge.vkradio.com (21:1/143)

Avon wrote to g00r00 <=-

On 12/10/17, g00r00 pondered and said...

There are two ways I think automated hatching can/will work:

The first is MUTIL could have an "auto hatch" section where you list
files and their file bases that you want to hatch whenever they're updated. Say base 12 file "nodelist.zip". To hatch it you'd just have your batch file that generates the nodelist copy nodelist.zip into it's filebase's directory and thats it...

Sounds good to me. And this would also allow for wildcard notation also
so as to pick up variations on a file name? Or would this require a
fixed filename to work?

If you can save the last filemane of the pattern somewhere, you could have a "replaces" option that adds that field to the .TIC. That part can be done in scripting.



... If silly had wings, this place would be an airport!
___ MultiMail/Win32 v0.49

--- Mystic BBS/QWK v1.12 A36 2017/12/04 (Raspberry Pi/32)
* Origin: The Bridge - bridge.vkradio.com (21:1/143)