search

jwolz / yajhfc

YajHFC (Yet another Java HylaFAX client) is a client for the HylaFAX fax server written completely in Java
https://www.yajhfc.de
Other
7 stars 1 forks source link

[FEATURE REQUEST] submission queue #14

Open jwolz opened 11 years ago

jwolz commented 11 years ago

Original report by Jonas Wolz (Bitbucket: jonaswolz, GitHub: jwolz).

Original issue 14 created by jonaswolz on 2012-12-16T14:11:19.000Z:

Hi,

This is just a feature request because I believe YAJHFC can't do this at the moment.

I'm having trouble sending many faxes at a time and I tried fiddling with Hylafax options (killtime, etc.) with no real luck. So I was wondering if the client could help me out. Basically I've noticed that in my case I can safely send 30 faxes in one throw (eg. 1 fax to 30 fax numbers). Any more and I'm risking to get job submission failures (kill time exceeded, max dials, etc.). That's because I usually have just 1 modem for each sending user.

So maybe a "fix" at the client side could help. Say I have to fax to 100 destinations and I tell yajhfc that my user can't be transmitting more than 30 faxes at a time (setting option). The client should first check the "transmission" tab and see how many jobs the current sending user has. It should then send the new jobs just as long as there's a max of 30. The client could also have an extra tab called "Submission queue" where the user could see his jobs that haven't already been submitted to hylafax. Of course, if the user tries to exit YAJHFC then he/she should be warned that the app should not be terminated until the submission queue is empty, or it will resume on app re-start.

Could this be useful?

If not and if people have managed to solve this issue on just the hylafax side, I'd be glad to move this topic to the mailing list (I actually already looked for help on this in the hylafax ML with no luck).

Thanks,

Vieri

jwolz commented 11 years ago

Original comment by Jonas Wolz (Bitbucket: jonaswolz, GitHub: jwolz).

Comment #1 originally posted by jonaswolz on 2012-12-18T08:57:12.000Z:

I can understand your problem, but I will not implement this on the client side any time soon. The main reason is that this is server functionality which should be implemented (or fixed) at the server side and not in the client in my opinion (I know this does not help you much...).

Implementing this on the client side would also probably be quite a lot of work since the client would be required to create and manage his own send queue.

jwolz commented 11 years ago

Original comment by Jonas Wolz (Bitbucket: jonaswolz, GitHub: jwolz).

Comment #2 originally posted by jonaswolz on 2012-12-22T00:20:35.000Z:

I know it can be a lot of work Jonas. I'll try to work it out on the server side. Thanks anyway!