Closed larsiusprime closed 10 years ago
Why not do somethign like in dbAdmin for spod, propose a handler implementation and let the user abstract it in haxe/php or haxe/neko ?
completed the proof-of-concept ! works & tested in neko, linux. will commit later. It need NodeJS server, so it will take a while to make it a pretty logger.
flash target not working because securityError 2028 any idea how to overcome this?
Maybe one of these? https://stackoverflow.com/search?q=error+2028+[as3]
@misterpah -- what's your approach? Are you just dumping flat files, or are you going to include a database?
currently thinking to dump flat-file. database is too much. i don't think people want to install database just for the logger.
got flash target working. compile with lime test flash -debug -Dnetwork-sandbox logger now also serve crossdomain.xml file. reference : http://old.haxe.org/doc/flash/security
Hey bros !
If I may help, crash logs are a uber key data ( for us at least ) so I would advise you to have them properly parsed and semantised and have multiple storage backend ( mondo/sql db should be possible ).
Good luck, luv yall !
2014-06-06 20:07 GMT+02:00 misterpah notifications@github.com:
got flash target working. compile with lime test flash -debug -Dnetwork-sandbox logger now also serve crossdomain.xml file. reference : http://old.haxe.org/doc/flash/security
— Reply to this email directly or view it on GitHub https://github.com/larsiusprime/crashdumper/issues/5#issuecomment-45367160 .
David Elahee
@delahee: sounds good, got any "best practices" for all that?
I also agree it'd be great to have multiple storage backends. We should have a basic network API for the thing that receives these crash dumps, and then the developer can have a flat-file-dumper or a fancy-database-storer mechanism behind that. So lets start with @misterpah's flat file thing, and then use that as a basis for more complex mechanisms.
I also think it would be super swell if the code for both the client crashdumper and the server-side crashdump receiver(s) could all be included in this repo :)
Another thought -- as of right now, there's no way to identify the user who sent the data, I guess you could log the incoming IP when you receive the data? Or should I generate GUID numbers with crash reports, or what?
Well I would say collect them with care, be able to explore, archive, find similar, filter similar and flag easily. Also a good thing is to monitor session length and player current situation in the game sequence scheme. :) Le 6 juin 2014 21:15, "Lars Doucet" notifications@github.com a écrit :
@delahee https://github.com/delahee: sounds good, got any "best practices" for all that?
I also agree it'd be great to have multiple storage backends. We should have a basic network API for the thing that receives these crash dumps, and then the developer can have a flat-file-dumper or a fancy-database-storer mechanism behind that.
I also think it would be super swell if the code for both the client crashdumper and the server-side crashdump receiver(s) could all be included in this repo :)
— Reply to this email directly or view it on GitHub https://github.com/larsiusprime/crashdumper/issues/5#issuecomment-45374023 .
Cool, good tips all.
My game-specific implementation includes timestamps for the beginning and end of the play session (should probably calculate & log duration just for convenience), and it also includes a dump of the player's initial save/configuration files, as well as a HaxeFlixel replay of all their input that got them from the starting condition to the crash.
Just pushed duration logging.
I would use https://github.com/stacktracejs/stacktrace.js/ for JS target.
almost complete. tested and works on linux, neko and flash.
Flash
neko
linux
edit : crashdumper-logger is the localhost server implementation. Of course it can be used as www implementation.
Ah, thanks very much! That's great!
@misterpah --
I'm thinking of creating a folder inside crashdumper for various backend implementations that the user can choose from. Do you mind if I use your crashdumper-logger code as our first?
i would be very happy if you do so. :)
Sounds great! This logger is very useful, by the way, been playing with it just now. I also figured out how to add stack traces to flash crash dumps, juts committed that.
I'll close this issue as soon as I bring your code over.
Code has been imported. I'll close this for now, if someone wants to add a new server-side implementation or expand up on what's there I'll be happy to accept it.
CrashDumper needs to be able to send the crash dumps somewhere useful, ie, to the developer.
Requirements:
I figure having the server-side script would be useful to people, too. I suppose we could write this bit in Haxe as well if we can output it to a ubiquitous server-side language like PHP? Then again I'm not picky, if someone just knows how to do this in raw PHP (or whatever the kids are using these days) that's cool with me.