#15 Different mode of operation



we talked about this some time ago (when I was not yet
aware of the better alternative to discuss this here).
I think it would be wonderful if esniper operated a
bit differently.

Currently, one writes batch files for esniper and then
starts the process. This makes it impossible to add or
remove auctions to a running process, the process has
to be killed first and then restarted. It would be
awesome if esniper operated in a way that allowed to
add and remove auctions from a running process without
having to restart it.

This would most likely also make it easier to monitor
what esniper is doing. Currently, it is impossible to
get the state that esniper is in. For example there is
no way to tell what auction esniper will bid next on,
etc. I am aware of the -i switch which is wonderful
while that of course only gives correct information if
the underlying batch files have not been changed in any

My vision is to couple this with some kind of very easy
http interface to control esniper. That would mean no
more media change (and no more stupid cygwin terminal I
cannot paste the auction number into but have to be
very careful of copying and typing it correctly from
the ebay website). Of course this is secondary, my
main point is the switch from the auction file based
approach to one of a background process to be
manipulated from the shell or possibly later via a web

I fully understand this will most likely entail a
rewrite of esniper core functions which for a product
that is otherwise running superbly might not make this
a top priority for you. I hope you will still consider
this RFE and think a bit about it. I certainly hope we
can discuss some of the merits and demerits of this
idea here.




  • Anonymous - 2005-08-04

    Logged In: YES

    I agree it would be awesome, but I don't have time available
    to implement it. If you (or somebody else) would like to
    take it on as a project and use esniper as a basis, that's
    fine with me. You can use esniper code for whatever you want.

    But I'd probably do it in Java. Much easier when dealing
    with multithreaded applications.

  • Paul Crowley

    Paul Crowley - 2006-05-31

    Logged In: YES

    This seems a fairly heavyweight solution to the problem.
    The standard thing for a Unix daemon is to re-read its
    config file on receiving a SIGHUP; that should be
    sufficient. In addition, it could write a status file that
    was kept up to date with what was happening on the auctions.


Log in to post a comment.