Re: [Flashcoders] Protecting Shared Objects
The program does have an installer and uninstaller, so leaving things behind shouldn't be a problem. I'm surprised no one else shares my co-workers' willies -- everyone is scared of doing something as silly as relying on souped-up cookies to implement a database. I shared your co-workers' willies, but that was years ago and no one could prove it. Danny ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Protecting Shared Objects
The program does have an installer and uninstaller, so leaving things behind shouldn't be a problem. I'm surprised no one else shares my co-workers' willies -- everyone is scared of doing something as silly as relying on souped-up cookies to implement a database. -Make Hawley Sam Thorne wrote: Just as long as you document it somewhere or off the option to uninstall, so that when someone actually is deleting things for a good reason, they can be sure they really are removing the whole application, including the archiver and it's backup. John Mark Hawley schrieb: I'm working on a CD product that needs to store a lot of data locally for easy lookup. Before your eyes glaze over and you point me at Zinc, know that this poor little product needs to run on OS 9, OSX, and Windows. Zinc doesn't do OS 9. But, aha, local shared objects! We can use them! Sure we can, but then there's a problem that some wiseguy could wipeout our entire database by clicking around in the Flash plugin settings for a good long time. So: the tentative plan says we could run a little executable via an fscommand at startup that checks to see if the LSO's are in good order, and archives them elsewhere if so. If they've been hosed, the little executable would un-archive the last backup and put them back in the right location. This sounds a little a rinky-dink, but it seems a heck of a lot easier than wrestling with a custom director wrapper and a real database. Just how icky does this sound to everyone? Anyone ever attempt something similar? Regards, Sam Thorne Interaction Design Web: http://www.native.com/ Tel: +44 (0)207 588 7970 Fax: +44 (0)207 588 7971 ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Protecting Shared Objects
Just as long as you document it somewhere or off the option to uninstall, so that when someone actually is deleting things for a good reason, they can be sure they really are removing the whole application, including the archiver and it's backup. John Mark Hawley schrieb: I'm working on a CD product that needs to store a lot of data locally for easy lookup. Before your eyes glaze over and you point me at Zinc, know that this poor little product needs to run on OS 9, OSX, and Windows. Zinc doesn't do OS 9. But, aha, local shared objects! We can use them! Sure we can, but then there's a problem that some wiseguy could wipeout our entire database by clicking around in the Flash plugin settings for a good long time. So: the tentative plan says we could run a little executable via an fscommand at startup that checks to see if the LSO's are in good order, and archives them elsewhere if so. If they've been hosed, the little executable would un-archive the last backup and put them back in the right location. This sounds a little a rinky-dink, but it seems a heck of a lot easier than wrestling with a custom director wrapper and a real database. Just how icky does this sound to everyone? Anyone ever attempt something similar? Regards, Sam Thorne Interaction Design Web: http://www.native.com/ Tel: +44 (0)207 588 7970 Fax: +44 (0)207 588 7971 ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Protecting Shared Objects
John Mark Hawley schrieb: I'm working on a CD product that needs to store a lot of data locally for easy lookup. Before your eyes glaze over and you point me at Zinc, know that this poor little product needs to run on OS 9, OSX, and Windows. Zinc doesn't do OS 9. But, aha, local shared objects! We can use them! Sure we can, but then there's a problem that some wiseguy could wipeout our entire database by clicking around in the Flash plugin settings for a good long time. So: the tentative plan says we could run a little executable via an fscommand at startup that checks to see if the LSO's are in good order, and archives them elsewhere if so. If they've been hosed, the little executable would un-archive the last backup and put them back in the right location. This sounds a little a rinky-dink, but it seems a heck of a lot easier than wrestling with a custom director wrapper and a real database. Just how icky does this sound to everyone? Anyone ever attempt something similar? sounds good. no better sol. from here. micha ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
[Flashcoders] Protecting Shared Objects
I'm working on a CD product that needs to store a lot of data locally for easy lookup. Before your eyes glaze over and you point me at Zinc, know that this poor little product needs to run on OS 9, OSX, and Windows. Zinc doesn't do OS 9. But, aha, local shared objects! We can use them! Sure we can, but then there's a problem that some wiseguy could wipeout our entire database by clicking around in the Flash plugin settings for a good long time. So: the tentative plan says we could run a little executable via an fscommand at startup that checks to see if the LSO's are in good order, and archives them elsewhere if so. If they've been hosed, the little executable would un-archive the last backup and put them back in the right location. This sounds a little a rinky-dink, but it seems a heck of a lot easier than wrestling with a custom director wrapper and a real database. Just how icky does this sound to everyone? Anyone ever attempt something similar? -Mark Hawley -- John Mark Hawley The Nilbog Group 773.968.4980 (cell) ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
