Hi,
After a little digging in the net, I came to know that Adobe is releasing
Apollo Alpha 1 installer at its lab around March 16. Check this out
http://blogs.zdnet.com/Stewart/?p=304
So till that time we can only read the pocketguide by Mike.
Thanks again,
Ashwinee
Note: forwarded message attached.
---------------------------------
Don't get soaked. Take a quick peek at the forecast
with theYahoo! Search weather shortcut.
--- Begin Message ---
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 alerts you the instant new Mail arrives. Check it out.
--- End Message ---
