File I/O in Central : What do you want?
The single most requested feature for Central has been File I/O support. So, how would you want File I/O implemented in Central? What would you use it for? What features / abilities do you want?
How would you rank the following in order of importance / usefulness?
- (A) Uploading/downloading files from a server.
- (B) Having a folder on the user's computer where apps could save or open files, without querying the user.
- (C) Being able to open or save files from/to arbitrary locations on the user's computer, using file dialogs.
- (D) Being able to create new files from arbitrary data in your app. Which files types would be useful here: text, xml, jpeg, etc.?
- (E) Being able to open, edit and save existing files. Again, which file types?
Post your feedback in the comments section.
Comments
-
(a) 10 (b) 8 (c) 10 (d) 8 (txt, xml, dbm, csv) 4 (image & audio) (e) 6 (txt, csv,xml,sql,dbm) didnt rank but gave em points.... cause id like more than one... you pretty much need generic file out of somesort to access file , this could be a controlled directory or any dir on the user's computer... prefer the latter but the limit may be ok.. just as long as we can read in. How would i use it, too many examples for this... pretty much there are so many utility apps on the desktop than use external files for saving or analysing or importing. I can make an app like that cause i cant read a file even tho i think the app would benifit from using flash as its UI nik
-
In order of importance: A,B,E,C,D
-
My take on it: A) This would be welcome, but it's a bit of a fringe feature - I can definitely see uses for it, but the most important type of data transfer with a server is covered already (ie. textual data). Rank: 3rd. B) LSOs? Again, text data is the most important file i/o, and this is covered by LSOs, which already save data to a specific folder on the users drive. Rank: 4th. C) Yes! Now we're talking. File i/o is one of the requirements for building applications. Add this, and Central suddenly becomes a powerful framework for building fully cross-platform applications. Without it, I have trouble seeing Central as much more than a crippled, proprietary web browser, with some built in e-commerce features. Rank: 1st. D) The ability to generate JPGs (and/or EPS, PDFs, etc) from a MovieClip would be a really wicked capability. This capability would make (A) MUCH more useful, and would provide a lot of great functionality for central apps. Rank: 2nd. E) Umm, isn't this basically the same as C&D combined? I guess it would be nice to be able to write an EPS, then have it pulled back in as modifiable shapes in Central to edit and re-save, but I can't see this being supported without massive development effort. Rank: N/A Cheers!
-
Chris WiggintonTake a good look at Konfabulator on how widget's are implemented. Great OS level integration with AppleScript being wrapped in JavaScript. I'd like to see something similar on the Windows platform as a transparent wrapper for the Flash Player with a Java API. Actionscript needs to go beyond fsCommand and getURL.
-
Personally, I find the last option Mike gives (Being able to open, edit and save existing files) the most important, although he doesn't give details on where files can be opened. As for file types, I would want to have any sort of text-based file (.txt file, XML, HTML, etc.) along with JPEG (photo editing app in Central!) and MP3/WAV (sound editing or DJ mixer app in Central!). Perhaps giving the ability for developers to build apps that could create a "specialized" file that only their open could succesfully open. For example, I build a game in Central and you can save your character's progress as a file on your computer (a Binary file perhaps?). So in order: E, C, D, B, A
-
The same way I'd use it in Screenweaver; to save my own custom file format with use in apps that local SO's just couldn't get for me because they are tied to that machine. For some of the developer based tools, just generating XML, it'd be nice to output it as most of digital toys I mess with are straight XML. A) If it worked like a browser, that would rock the hizzouse! It'd be nice because you could share images you uploaded into your app as well as other files your maybe managing. Status of said files uploading beyond what a frikin' browser does would be great too, like a getBytesLoaded kind of thing if that's possible. B) No thanks. This is just like Director's setPref, but since we got local SO's, I don't see the point. C) Hellz yeah. If the user can access those directorys via explorer, I'm all for that. If the ability to set the filetype to like .jxl instead of .xml (even if it were just a string), that would rock too. D) XML, definately. Creating images is pretty cool, but more of a one time type of thing... I don't really know what I could use that for in a serious app. E) No thanks. This goes with above in dealing with outputting files; all I need is XML, but a portable local SO would be kinda neato. Like, I could have my Central app read it back in from a user's desktop or something... I'd assume it'd be faster, but if not, then I'll just stick with XML. SO, order of rockness: C, D, E, A, B
-
For me, the big issue would be lowest possible security risks... email software is a classic example of how *not* to do things... we've been pretty good with the Players but there have been a few times we've had to tighten the sandbox, with the result of breaking existing apps... local file access is a big step beyond Players, particularly with one-click installation... taking things slow and sustainable would be my first choice, thanks. jd
-
Justin Hall(A) You should be able to upload a file by selecting it with a file dialog box. Using HTML pop-ups can take too long one by one as well. Make it so you can select multiple files. (B) I have data to store, but I don't want to it to be a hog for the user's LSO storage. It would be the most secure. Central is a hybrid application, but it tends to be 80 percent web based and 20 percent desktop. Other applications that are vice/versa are called desktop applications. If security is too big of a risk for true File I/O then this would be a good alternative. (C) It would be nice, but will this open more cans of worms than solve problems? If Central had a way of limiting file types and/or restricting directories through default settings for OS's and ad-hoc user administration, then this would be ideal. (D) XML, jpeg, text, swf (Flex) (E) XML, jpeg, text, swf (Flex)
-
Chris VelevitchA (up & down loading files) and D (create files formats: Word, Excel, PDF, Open Office) are currently the most important.
-
Randy DrisgillI agree with David Bisset, screenweaver does a pretty good job of this. You can create applications that can save data (usually simple txt or xml files for me) to whereever the user would like. I think this is a feature most end users are accustomed to in traditional applications.
-
JD: I understand the concern of suddenly opening up to complete system access and the issues it could create just because it being a new feature. I think if we just have limited access to read/write to files that would be fine. By limited access i means flash only lets u read/write to a certain dir like local objects, only this would not be limited to 100 kb or some user setting. The flash developers makes his own file dialog or watever, just give me write access. If i need to modify binary files i can read them in. File read/write should have a binary/ascii flag. After that i would say add a few functions to read binary data. this was the user can read in any file and manupilate in a binary manner or text manner... I think upload files is extremely important. The point of central is OCC. Now if i can save configs, export data etc to files, i may want to share some of this data between users, or save the data to the server for logging, profiling, etc. so u can restore from server, send files to another user, backup, create/acess an online archive etc. at minimum i think read/write and upload/download should be there... even if limited to where on the hard drive this can be done. for me the functionality is more important to where it is stored. but if i can have this for anywhere on the hard drive i would be delighted and i'm sure i can seeing this kind of functionality provided to anyone making a non profit app for central being abused. People are not accustomed to flash having full file system access and suddenly giving this functionality may cuase it to be abused or overused and surprise users who have been associating flash to being not have filesystem access. A few cases of abuse is enough to give flash a bad rep, like a few years ago when flash intros made ppl think flash sites are only splash pages nik
-
(a) 10 (b) 8 (c) 10 (d) 8 (txt, xml, dbm, csv) 4 (image & audio) (e) 6 (txt, csv,xml,sql,dbm) Mybe included easy database driver for good sort date and numeric data? Mybe Access or?
-
a)10 - certainly a method of getting user files up to a server b) 5 c) 9 - nice but too open to abuse, it wont take long for someone to cause problems with this, maybe if the file types were restricted but i still dont like it; currently flash has a good security record d) 8 - swf, jpg, txt,xml,mov - yes please! e) 8 - as above !
-
A is essential, but you need to ask the user. B the user has to be able to control how much space you can use on their harddrive. D sure, give everyone binary data in/out.. image files would be awesome and so would saving flv files locally that could be played back locally and uploaded later!!! E - any file types but FLVs and some image file formasts would be awesome!! Central is in a space somewhere in between the browser and single applications a user installs. Don't mess up on security or you will pay and pay and pay for it. I know marketing people hate security but you have to have it or people in IT departments will resist Central.
-
BenLOrder of importance: (D) Being able to create new files from arbitrary data in your app. text, xml, jpeg, swf. **Also capability to create new directories(folders), EVEN if they are in a special reserved directory.** (A) Uploading/downloading files from a server. (C) Being able to open or save files from/to arbitrary locations on the user's computer, using file dialogs. (E) Being able to open, edit and save existing files. Again, which file types? (B) Having a folder on the user's computer where apps could save or open files, without querying the user.
-
For me, I'd be happy with the kinds of data that Flash can load dynamically, such as text/xml, jpgs, mp3 and maybe MovieClips. (C) is top for me, followed by: (d) (a) (b) (e) Thanks, Derek
-
(A) & (C). Everything else is a subset of these. For upload to the server, it should ideally be in a method and format that allows *standard* server side file handling, using the techniques we know and love in JSP,CFM,PHP,etc. Otherwise, we can't easily use the same server side processing for similar upload capability from a browser based app. Arbitrary file load/save to any location on a localdisk should *always* have a dialog. For small saves that you don't want to bother the user, likie confi info, you already have LSO. I'd be interested in standard text based file formats: XML, PDF, Word/Excel (as XML?). While I'd want the ability to arbitrarily write out a file string, MM (or 3rd parties) could also write components for each popular filetype, so that you pass in data and it'll take care of building up the file structure. Sell different file types through the DRKs, for those that don't want to roll their own. Probably a stretch, but I'd love to see file access done in a manner that can also be used with the browser plug-in and the projector. If I write an app to target multiple delivery channels, I'd prefer to have similar functionality in each version.
-
MkrisherA) - need this in order to make Enterprise level Web based application. My main focus with Central has been the enterprise and right now it does not stand up to a browser because there is no way of doing uploading and downloading of files. I think just implementing this would encourage a lot more useage of Central as an application framework. D) - being able to store application data as known filetypes locally would help as well. Esepcially for times when apps are not connected. Maybe "supporting major filetypes" (i.e. restricting) will help with the security sandbox and still allow applications the ability they need. I think a save dialog for the user should allow them to choose where in the filesystem the file gets saved though. Thanks for asking.
-
Rank: C, D, A E B Summary: C, D and A are equally important. E will be very useful. B seems fairly intuitive. Solution: I really think that you guys should focus on what Java does and improve, build upon the foundation already laid out. Maybe even, policy files could be used in the mix to preven, allow certain applications from writing to certain directories.
-
asdB,C,D,E,A
-
It needs to have access to local files in a secure fashion. I think that the developer should be able to prompt for an open file dialogue. The user would then select a file, and at that point some kind of handle is returned to the code. You would then use that handle to load the content through the appropriate facility. Files allowede would be anything text, plus all the media types(jpg,swf,mp3,etc.). To be safe I think local file access should always be through a prompt, and loading local files in the background should not be allowed as usual. In terms of saving files, that could be dangerous for the usual reasons. Again the only way I would allow it is with a prompt. No backgound saving. So any local file interaction would have to be allowed by the user, basically. Maybe there could be an option like: "trust local file access always for [domain]" I am not sure. The other thing that would be killer is: >>FTP If there was some way to allow transfer of files up to a server, that would definitely be something. I have that exact scenario right now with a central app I developed. In order to use the application, I must use CFFile and CFFTP on the server to accomplish my goals. If I could use FTP on the client, it would make a lot more sense for my application. Anyways, my 2 cents.
-
Sorry to post again, but the more I think about it, the more I love the idea of local FLV file support. You can send() any data into it and recording and playing back audio and video would be great. Unlike shared objects you don't need to have the whole thing in memory at once... Cheers, -Brian
-
CortHi Mike, Thanks tons for asking for input on this one. The ideal scenario is obviously to have A and D+E. With D+E allowing both the writing of arbitrary binary and text data with typical file access commands. If that can be done without making Central a virus writers dream - that's certainly ideal. But I don't belive that it's a realistic option. I'm not a security expert by any means, but I imagine that the system would be a lot more reliably secure by restricting access to a single directory and a small set of known file types, as the options in your question implies. Assuming that that is the case. Here is what I would look for realistically, in order of importance (D+E) Being able to create new files from arbitrary data, to open them and save them. Limiting the formats in order of importance to the following list .swf .flv .txt .xml .jpg .htm .mp3 (D) is number one for me, but I can't imagine it without (E) as well. The ability to create new files to store data. This is because the primary use of such a feature would be so that if I had a calendar or photo album application, that I could tell users that they can back up the important data they have input in my app or transfer it to another computer by just moving the save.swf file in the C:/myApp/ directory - or by copying a folder filled with files. If I had a video conference application I'd like to tell users they can back up their video similarly. Currently to do this I would have to either use a server and an email address, and some complicated server based process - adding complexity to the app, especially for offline mode, or limit myself to text data and build an external executable tool to back up the shared objects which, of course, partially defeats the purpose of using central. On file formats --------------- Swf and flv would be my number 1 and 2 Desired file creation types as they can include any of the others for display purposes. They work equally well for media and data, and data would be stored in a parsed form. Also, macromedia controls the formats, which could insulate any app we create from variations in future versions of other popular file formats that MM doesn't control like mp3 or mov. This would also allow all of the jukebox, photo album, and video album apps that folk would want to build by using comm server, without getting bogged down in political and legal flack from enabling infinite napsters. Being able to save audio and video data in flv could also enable better video quality for a comm server app by allowing a user to encode their audio or video without worying about the real time bandwidth contraints (especially important when sending data upstream with current cable modem setups). After that I would like to be able to read and write txt and xml files. In general, I'd rather save multiple xml files as ready to use objects in a single swf than a number of xml files that need to be parsed by the interpreter for use later, but being able to read and write in these file formats would be key to enabling a good input/output process for data in central to work in a larger system. After that in priority would be jpg, then html, then mp3 (for those willing to brave the political/legal waters that I would tend to avoid by using flv). On file locations ------------------ I'd be perfectly happy if this file reading and writing were confined to a single directory for security reasons, though I would prefer file access through dialog boxes if it could be done without hampering security. Finally (A) would be a great feature regardless of the other options. If we don't have the others, of course, it becomes much more important. Thanks again for asking. Glad to hear progress is continuing!
-
(D) and (E) are definitely two sides of the same coin. Together they relate directly with (C), no question about it. I mean, if I'm editing documents of some sort, we shouldn't assume they are located inside Central's program folder. In the same fashion, if I'm creating a file from a Central application, I most probably want to store it in 'My Documents' or something like that... (B) looks to me like a restricted version of (C), which can come in handy if my application needs to manipulate 'internal' files, and there's no need to bother the user with message boxes... (A) is a must.
-
(D) & (E) are definitely what you want to implement. the question of filetypes, however shouldn't really be that high on the priority list... i see (B) & (C) as definite nonos. you don't want dialogue boxes popping up for primitive routines as file creation. i see too many problems with such an implementation and it's interferance with your applications. (A) could be reworded to be the "server version" of (D) & (E). Once you have arbitrary access to server and local resource, download/upload become trivial
-
These are great comments. I'd love to hear more from people about specific app goals that matter to them. For example: - external backup files for my app - fancy display/interpretation of another program's output (weblogs, for instance) - creating files for use by other programs (Word files, address cards, etc) - saving data for my own app, but without using Local SharedObjects.
-
Posibility to check image dimensions(or mp3 props), size when user selects them
-
It'd be nice to have local access to FLV's and FSO's that were made via Flashcom, that way, my Flashcom app can work offline at need be. I realize that some of the Flashcom service stuff would have to be built into Central, but there are a lot of "local" interactions that would be nice.
-
Besides, the local access to FLV's with Flashcom SS messages would be a great hack to get the "length" of an FLV.
-
Actually, going off that idea, if Flashcom was built in with it's own "apps" directory et. al, and all security sandboxed, I could run local Flashcom apps; being a server and client at the same time would enable me to build some pretty sophisticated apps!
-
Two words Drag n Drop Like in screenweaver - makes a hell of a difference.
-
Jesse, peer-to-peer Central/Flashcom. What a fantastic idea! Probably way to big a foot print for Central and serious security issues to work around but an awesome concept. -Brian
-
A built-in encryption mechanism would be nice.. so it would be easy to save data in a secure file.
-
DanAll of the features would be great. Having to mess around with hidden frames, JavaScript & localConnection just to do something as trivial as uploading a file is a nightmare, many business applications that could have been built in flash has had to be scrapped in favor of other formats because of the lack of I/0 support.
-
Danwhat is mildred going on about?
-
ftp class.... yknow, a class thats gives access to login into ftp, & telnet... i magine that.... with file i/o and that u could make a cvs app in central? file syncing apps etc ... now thats something i would want to make, something that could be used on a daily basis... nik
-
File access would be a nice feature. It could be restricted to some directory etc, but it should be there. I hope this will come to the normal Flash player too. At least, when creating stand-alone projectors, it would be nice to have a standard file access. All the fscommand hacks aren't really user friendly. One thing I would like to see in Flash, is secure sockets (SSL). That would make it possible to create a number of different apps. Yep, and file uploads! Thanks Mike
-
Also - It would be nice to be able to getthe Cursor position outside the flash player ... IE - if one needs to build in app that needed to detect user activity .... there is loads more but I think its already been mentioned....
-
My ranking takes into account that I already use a filesystem with Central/Flash applications (Based on local shared objects and available open source). Anything that I can't do using the IOS/FS, I can do via the browser (file uploads, downloads, back-end-scripts to create image and other file formats etc.). So this is the added-value of a Central File-IO Scheme. I won't have to invoke the browser, HTML and server-side code. (A) It would be great to do this without invoking the browser. For example, selecting and uploading .jpg and other mime file types. Any file saving and file format capabilities that you add to Central (eg, .jpg files), I would DEFINITELY need to see these also as upload-to-server capabilities. (C) and (E) In conjunction with (A). All lumped together. A file-dialogue window is necessary. I can do this in HTML/Browser, so I should be able to do it in Central also. But there is only a point to this for the types of files that will be shared OUTSIDE Central, with non-Central applications. Otherwise I'll keep using IOS/FS. See (D) for file types. (D) But be careful! I worry about rogue applications that can create executable files. Also, this is where the speed of ActionScript becomes a limiting factor. I can imagine writing code to manipulate .html, .xml, .csv, formats like PostScript even. But writing my own graphics libraries in ActionScript to spin my own .jpg, .png, and .gif files?? - that's too computationally intensive, and probably better dealt with as a high-level feature (MovieClip.saveAsJPG() - say). If you DID add high-level features to be able to dynamically save a movie as an image, illustration, movie, or even sound file - then this make Central REALLY powerful. (As it is, this sort of stuff has to be done server-side right now, when the client computer is perfectly capable!) (B) Why? This is what LocalSharedObjects are for?
-
COMPLETE BEGINNERhi, everyone. as the name suggest, i am one. and i need a little help in learning the basics of file input output in flash mx. if there's anyone here kind enough, would that someone please email me something that could get me started with my own project that includes file input output. thanks.
-
jockiehi... i have problem with store data to txt file. it is possible to store data to txt file from flash?? if any one know, please help me?? please send to my email.... thank's before..
-
Alex MunteanAt last! Something I thought Central has since its first inception. After downloading the SDK I frenetically scanned through the help only to discover there's no file I/O API! (LSO do not count ;)) What I expected was something like FileSystemObject from Windows Scripting Host (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/jsobjfilesystem.asp) of course with enough security restriction so a malicious app cannot wipe your HDD :) (A) I think upld/dld files from a server should be a must. It can be done from virtually every browser and any Internet user is familiar with it. Rank 1. (B) Shell.*LocalInternetCache API is already doing this do some extent (not caching potentially dangerous files). What will be new here? Rank 4. (C)(D) I see these two as a unit. If an API enables you to open and save files then it should also let you to create new files. However, even using file dialogs, the security risks will be very high. Even if the range of files is limited to several "benign" file types (same as Flex), still it will enable one to delete all your JPEG files or anything like that. If the API from (C)(D) will be limited only to a folder (and all its subfolders) then it will be safer. However at that point (B) becomes obsolete. In the end it is a problem of trust. Did I dld something directly from MM? Or one of the approved apps from Exchange? Then I can be (at least partially) sure that nothing wrong will happen. If you realistically think about it the risk is even higher with all the free or trial stuff that gravitates around on the net. And most of us are using it everyday. Rank 2. (E) This is the same question as (C) but without file dialogs. Rank 3.
