Home
Why
snipe
?
Compare
FAQ
Community
Terms
Contact
My Snipes
Home
Why
snipe
?
Compare
FAQ
Community
Terms
Contact
My Snipes
Menu
Home
Why
snipe
?
Compare
FAQ
Community
Terms
Contact
Username
Password
Login is SSL protected. By clicking on "Log in Now" you agree to gixen.com
terms of usage.
Search
Gixen.com Forum Index
->
Support
Post a reply
Username
Subject
Anti-Bot check:
Enter characters from the following image:
Item ID warning
Please provide eBay item id number (unless provided already) in the post message if you have a question about specific item.
I cannot investigate an issue without it
.
Message body
Emoticons
View more Emoticons
Font colour:
Default
Dark Red
Red
Orange
Brown
Yellow
Green
Olive
Cyan
Blue
Dark Blue
Indigo
Violet
White
Black
Font size:
Tiny
Small
Normal
Large
Huge
Close Tags
[quote="Spiritussanctus"]Mario my point is that the earlier snipe I had entered via the web interface did not fire either. Why is that?[/quote]
Options
HTML is
OFF
BBCode
is
ON
Smilies are
ON
Disable BBCode in this post
Disable Smilies in this post
All times are GMT - 8 Hours
Jump to:
Select a forum
Gixen
----------------
Announcements
Support
Suggestions and Ideas
Impressions
Blog
Topic review
Author
Message
mario
Posted: Tue Oct 22, 2013 1:20 pm
Post subject:
I am glad that we were able to find some common ground, and sorry you missed that one. Hopefully this discussion and FAQ update will be useful to users in the future.
spiritussanctus
Posted: Tue Oct 22, 2013 8:08 am
Post subject:
Mario: appreciate the reasonable response and for changing the FAQ. As an engineer myself (ASIC designer), I'm content as long as any edge case behaviour is clearly specified.
Most of my surprise stemmed from the fact that I was expecting a "Modify" action to have somewhat transactional semantics...either one action succeeds or the other, and I was fully prepared for my late modification to fail. If I'd understood beforehand that it was an implicit "delete and re-enter" subject to a race window where no bid makes it to eBay, which your FAQ now makes clear, I wouldn't have blinked!
mario
Posted: Tue Oct 22, 2013 6:50 am
Post subject:
I updated the FAQ, under question "Can I change my bid after I've entered it in Gixen?"
The added text is the following:
Note that all edits, deletes and new entries should be completed at least 2 minutes before auction end. In case of late edits, Gixen will make every effort to 1) cancel the edited snipe if already in progress, and 2) execute the updated snipe, but neither is guaranteed to succeed. It is, however, more likely that late delete / cancel will be successful than late addition, so in most cases late edit will result in cancelation only.
mario
Posted: Tue Oct 22, 2013 6:42 am
Post subject:
Cupid wrote:
To continue the discussion... the problem with not cancelling when there is a lower snipe in progress is that, unfortunately, creative types are likely to use such a feature to take two bites of the cherry on auctions by deliberately making late edits...
This is true, but it's not a big deal. I would implement a useful feature despite that, if I didn't see other problems with it. Just to mention one - what if user makes 10 or 20 edits within last two minutes? Even more than that is possible with Gixen API.
Cupid
Posted: Tue Oct 22, 2013 2:34 am
Post subject:
The access to this area is via a tab titled 'Community'... As such it is an open forum for everyone to post about and discuss Gixen related topics and issues... For those not prepared to engage in such a discussion and just expect everyone to agree with their views, this is not the place for you, as the feeling that you are most likely to experience, with such an attitude, is one of frustration, which is not what you are after.
To continue the discussion... the problem with not cancelling when there is a lower snipe in progress is that, unfortunately, creative types are likely to use such a feature to take two bites of the cherry on auctions by deliberately making late edits... no matter that such action, in my view is counter productive, and certainly antisocial to the wider Gixen community, given the amount of server resources involved in providing that behaviour, which consequently are not available to other users that have decided on their maximum bids well in advance of the auction closure.
mario
Posted: Mon Oct 21, 2013 5:27 pm
Post subject:
Anonymous wrote:
The warning merely states that the snipe may not be honoured. It doesn't say the previous snipe may be cancelled and nothing replaces it. Also, the "for bidding" app, which I paid for and is apparently written with the Gixen admin's support/consent given that it requires a subscription, doesn't display any warning. Why not just add an FAQ entry explaining this, rather than fighting with your customer?
I never said I am not open to adding it to FAQ, only that an existing warning exists. Sure, it's not detailed enough as there is no space for it, but it does not take a lot of imagination to predict that the previous snipe may be cancelled. I will add this to FAQ nevertheless.
I am not responsible for the "for bidding" app. I don't make it, I don't charge for it. But I will pass the suggestion to the author to display a warning for late edits. The app is pretty new and may not include everything that the Web UI contains.
And I am sure not fighting with the customer - I see it as a discussion. I do my best to listen and support my users pretty much 24/7, but if you expected no discussion at all and attitude "customer is always right", Gixen is a wrong place for that, and I am a wrong person for that as well.
Anonymous wrote:
I found your attitude/response to a simple question extremely defensive and reactionary, you're apparently not even open to adding an FAQ entry, let alone doing something more creative like not cancelling if a lower snipe exists.
Again, not true, adding it to FAQ is fine. Not trying to cancel what is a deleted entry, and even evaluate conditions, is not an option in my opinion. It's too messy, both technically and from the support perspective.
Anonymous wrote:
I will not be renewing my Gixen subscription. I encourage others to find products where the developers don't have this sense of entitlement or "my way or the highway" attitude. Good luck.
I think my attitude is far from what you subscribe. If you take an honest assessment of things, I think you will conclude that you being upset is far more result of a missed auction than what I said here.
Guest
Posted: Mon Oct 21, 2013 5:04 pm
Post subject:
The warning merely states that the snipe may not be honoured. It doesn't say the previous snipe may be cancelled and nothing replaces it. Also, the "for bidding" app, which I paid for and is apparently written with the Gixen admin's support/consent given that it requires a subscription, doesn't display any warning. Why not just add an FAQ entry explaining this, rather than fighting with your customer?
I found your attitude/response to a simple question extremely defensive and reactionary, you're apparently not even open to adding an FAQ entry, let alone doing something more creative like not cancelling if a lower snipe exists.
I will not be renewing my Gixen subscription. I encourage others to find products where the developers don't have this sense of entitlement or "my way or the highway" attitude. Good luck.
mario
Posted: Mon Oct 21, 2013 1:35 pm
Post subject:
Spiritussanctus wrote:
Surely there must be a notion of an atomic update transaction on the database backend?
Atomic database updates have nothing to do with action taken on the data read before the update.
Spiritussanctus wrote:
I strongly suggest you update the FAQ to reflect these implicit surprising behaviors.
There is a clear warning displayed to complete your updates 2 minutes before auction end. In addition, an additional warning is issued when you do such an update despite the previous warning.
Spiritussanctus wrote:
I can 100% accept that a late snipe isn't honoured. But to have it result in data loss (which is absolutely what this was) with no feedback seems unacceptable.
This is *not* data loss. No data is lost here. Action is different than you hoped for, but no matter how you design the system some cut-off time, and some behaviour when edit is made too late has to exist. In Gixen's case it's best effort to both cancel previous snipe and execute the new one.
Cupid
Posted: Mon Oct 21, 2013 9:36 am
Post subject:
Once a snipe is in flight it isn't a matter of what data is on the database, but what should happen to the process that is already executing when a request is made to change the outcome of that process... the process would not be reliable enough if it were constrained to consult the database every second just to see if a change has been made.
Of course it is more important that the original snipe is cancelled when a user tries to delete the snipe, or when they lower the amount that they are willing to pay... but to have a different procedure for the case where a user wants to increase the amount seems over the top, particularly when the behaviour is pretty well understood by the majority of Gixen users.
Spiritussanctus
Posted: Mon Oct 21, 2013 7:10 am
Post subject:
Surely there must be a notion of an atomic update transaction on the database backend?
I strongly suggest you update the FAQ to reflect these implicit surprising behaviors. I can 100% accept that a late snipe isn't honoured. But to have it result in data loss (which is absolutely what this was) with no feedback seems unacceptable.
mario
Posted: Mon Oct 21, 2013 6:31 am
Post subject:
When you do an edit, every attempt is made to cancel any previous snipe first, and then execute a new snipe, if possible and enough time remains. When there is little time left, it's common that the first action succeeds (as it requires less time to stop execution), and the new one doesn't.
You may not like this choice, but it was my decision when designing behaviour to err on side of inaction, instead of risking an undesired action.
Spiritussanctus
Posted: Mon Oct 21, 2013 6:16 am
Post subject:
Mario my point is that the earlier snipe I had entered via the web interface did not fire either. Why is that?
mario
Posted: Mon Oct 21, 2013 12:59 am
Post subject:
The final edit you made from "For Bidding" app was made only 9 seconds before auction end. That's far too late. You should complete all your edits 2 minutes before auction end.
spiritussanctus
Posted: Sun Oct 20, 2013 7:03 pm
Post subject:
I realized my post wasn't very clear: the original snipe of 162 was entered via the gixen.com web interface well before the auction completion date. The final snipe of 177 entered via "For Bidding" within 1 minute of the auction's end is visible on the web interface, so it's presumably not a case of ForBidding zeroing the snipe.
spiritussanctus
Posted: Sun Oct 20, 2013 6:39 pm
Post subject:
BTW: under "status" for both the main server and the mirror, it just says "ENDED".
spiritussanctus
Posted: Sun Oct 20, 2013 6:35 pm
Post subject: Missed bid
Hello,
I am a subscriber, and my Gixen bid for 231069295215 was not entered. I originally entered a snipe of 162 via the web, and then just prior to the auction ending, entered a snipe of 177 via the For Bidding iPad application I purchased from the iOS app store. Neither bid was submitted to eBay, and the item was sold for a lower price. Even if the ForBidding app is at fault, given should not have tossed my earlier bid which was entered via the web interface.
On a related note, I observed the For Bidding app occasionally zeroing my snipes, in addition to crashing and entering repeated refresh loops on my iOS 6 iPad. But those are minor relative to lost snipes!
Thanks for investigating this, I'm now concerned that either there's a Gixen server side problem, or I should stop using "For Bidding".
© 2006 - 2023 Gixen.com. Forum powered by phpBB © 2001, 2005 phpBB Group.