Hi, Not yet. Soon. :) -David Adobe ________________________________
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of ashwinee kumar dash Sent: Monday, March 12, 2007 12:32 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Re: DB access in Apollo Hi, I am just curious to know if Apollo Alpha 1 installer is available for download. If not how how come some developers are calling themselves Apollo developers. If it is really available for download ,would i be able to get it? Thanks Ashwinee hank williams <[EMAIL PROTECTED]> wrote: Wow Shaun, Lots of stuff to vehemently disagree with. > > > Your overstating the importance of a db on the client. Well, he may be. But let me just say this. For the last 20 years, most desktop apps have use a client side database. Generally in the MS world it used to be a library called Jet that was an embeddable version of Access. And almost every pc based app used it. So the idea that Dorkie is saying something out of the mainstream of thinking as it relates to client side development is just wrong. > Bringing the desktop and the 'net together is one of its(Apollo's) > strong points. At least thats what it seems like from where i'm sitting. > Translation - bringing local file storage to web applications is Apollo's strong point. What we are arguing about it *how* best to do the local storage. You make your point as though the database issue is not relevant to "bringing desktop and 'net together". What other important issues are there in this regard aside from storage? > >> > >> There are already apps in development that would use a database: > >> > >> - Java Docs Generator (in dev) - documents your code, stores and updates > >> java docs in db > > You wouldnt want to store the documents in a DB, thats just dumb. > Metadata perhaps, but there are other options. > No, is isn't dumb. It might be the right solution sometimes and sometimes not. But its not dumb. Databases provide integrity which you dont get with file system storage. This is a design decision and trade off and it is not a clear cut decision. > >> - Project management software (in dev) - keeps track of tasks, projects > > This information you would probably not want stored in a client DB, more > likely this would be stored on a DB server and accessed from the client. > Usually more than one person wants to see how a project is tracking. > If you must have it on a client(no server) then, use a xml document, at > least its portable, that way you could send it to another person so they > could see the project details, and you can render it using XSLT in any > format you like. > The entire point of Apollo is disconnected use with synchronization. You seem to be arguing with your comment that for some apps this is a bad idea. NEWSFLASH: You dont need Apollo if everything is going to be server based. To your point about XSLT this is just silly. The model you are describing is not an app model its a web page model. Imagine saying to microsoft "hey guys lets just use XSLT to display those PERT or GANTT charts". > >> - Photo management software - accesses the filesystem like Adobe Bridge, > >> search and sort > > Nah not really, simply use the filesystem to store the assets(images) > and store the metadata in a file that points to the filesystem. Same as > iTunes. You sort and search the metadata not the assets. > I cant say i'm sure about this - but I am *fairly* confident, that the iTunes XML file is an output format and that it also uses a native file format for its actual operation and management. I think it just periodically exports the database in XML format. But whether it does or not, the issue is whether you want a RAM based application, or a disk based application. Plain and Simple. Despite your implied contention, it is a well established notion that there is value in storing your data on a hard disk and only changing the bits that need to be changed instead of writing out the whole file after every modification. More importantly, deveoping this way is *much* more work for table based applications. You have to create your own indexes for sorting, etc. SQL *does* make life easier, and that is the point of all this isnt it? > >> - Music software (already created by an Adobe engineer) - keep track and > >> sort mp3's (itunes, windows media player, winamp, etc use their own > >> built in > >> db) > > iTunes uses an xml file.. Dunno about the others. iTunes connects to the > 'net when it needs access to a DB, that hasnt stopped it being a huge > success as far as I can tell. > What a silly comment. itunes is successful, therefore there is no need for disk based applications!? > So, a client side DB is not as critical to me, as it to you. Sure it > might come in handy, but I can live without it. > Well, this is the first thing you have said that makes sense to me. It is clear that depending on what you are developing and how you like to develop that your mileage may vary. But I guarantee you this. If I had a database and all you had was the flash api and text file storage, that for any kind of data intensive application I would be able to write a more robust application - or at least the data handling piece, and I would be able to write it faster than you would with just file storage. Regards, Hank ________________________________ Never miss an email again! Yahoo! Toolbar <http://us.rd.yahoo.com/evt=49938/*http://tools.search.yahoo.com/toolbar /features/mail/> alerts you the instant new Mail arrives. Check it out. <http://us.rd.yahoo.com/evt=49937/*http://tools.search.yahoo.com/toolbar /features/mail/>
