>> lots of questions from a few different people......
CAVEAT: Robin may completely disagree with me here - but this is just from the perspective I got last week at the FCS workshop. FCS is more than just ShareObjects (as it is also a streaming video and audio server as well).
FCS uses the MM concept of SharedObjects to store data that needs to be in sync on both platforms.
Using remoting is not the same thing because FCS can push and pull data - from either client to server or the other way. FCS also allows the server or the client to call functions on the other platform at will. Remoting is a pull technology initiated by the client end (just as you would do it in a web browser if you were accessing a webservice). FCS is much more powerful than that.
There is no "database" as such. Persistent (ones that stay even after the server and the client are shutdown) SharedObjects (which is what you want) are a file stored in a directory (either on the client or the server). You may choose to not have "persistent" SharedObjects on the server side but may simply just get the information as it changes and update your own storage system accodingly.
On both the client and the server you can have an "onSync" method attached to a SharedObject that is called automatically when any data changes are detected (it is a little more complex than this, both sides can say when objects have been changed or deleted or are new, etc. etc.). The technology to implement this, though, is seamless to the programmer. You just set variables on either side and all the other interested parties get the updates.
This means you can do a number of things - on either end.
You can simply just use the data as it comes through or you can use it to post to either a local or remote database or just update certain areas on the client. You can also using remoting on the server end to then call webservices in Cold Fusion - or other exposed objects and services - to deal with any of the changed data.
In terms of "flat files" you cant really think of FCS in that way. Although I dont know the actual technology in the ShareObjects, think of them as discrete keyed pieces of information. How you build the app will depend on how much traffic you will have to handle. For example, if you are sharing at a "record" type level (not that "record" is a concept as such - but lets say a regular set of related pieces of information) then if anything in that record changes you get a notification telling you that record change and all the data is already available to you. If you stored everything as individual pieces of information then only when one piece changed would you get notification. It is about designing the correct granularity for the application you want to deliver.
For example, if I am designing a stock portfolio systtem, I may decide that the "granularity" is anything to do with an individual stock. If any of that information changes (ie. the price, the volume, yearly averages, etc. etc.) I want to have that data synchronised and be notified about it at that level. So, if the price changed, I would get the complete "record" down with a notification that "something" changed. I would then just get the data from my SharedObject, update what I needed to on the client (without much regard to "what" actually changed) and redisplay my calculations (such as value of my stock, or total value of my whole portfolio, etc). If information on a stock does not change - there is no traffic - and my application just happily sits there displaying whatever it did last time an update came through. I dont need to poll, I dont need to call a remote service. It just happens.
BUT - the key to designing the application correctly is getting the right granularity.
An example that Robin gave was of a Theatre Booking system. Here the granularity was a "seat". As soon as someone clicked on a seat to "book" it, the information was sent to the server in a SharedObject. All the other booking apps that were running were then also automatically notified that the status of the seat changed, and they updated their display accordingly. Then, if the payment went through the seats were booked, otherwise they were released. And, once again, the dynamica status was communicated automatically to all connected applications that needed to know.
The classic example, in fact, is a "chat" application - like IRC (not like webchat) - that just updates in real time. While no-one is talking - nothing happens - when someone sends something it is stored in a SharedObject and every application connected to that SharedObject gets told, and handles it accordingly.
As far as "local" databases are concerned, Flash uses the same "SharedObject" technology on the client as on the server. Once again - think of small pieces of discretly identifiable data that only gets transmitted if it has changed.
I have experimented with this. If you set a piece of data into the stored object, it transmits it to the server. You can set the same stuff into the same object again and again - and it wont transmit it any more. However, you put different stuff in, and it transmits it.
I suppose that is a lot of information - but I think it does describe some of the core functionality of FCS fairly well.
Gary Menzel
IT Operations Brisbane -+- ABN AMRO Morgans Limited
Level 29, 123 Eagle Street BRISBANE QLD 4000
PH: 07 333 44 828 FX: 07 3834 0828
****************************************************************************
If this communication is not intended for you and you are not an authorised
recipient of this email you are prohibited by law from dealing with or
relying on the email or any file attachments. This prohibition includes
reading, printing, copying, re-transmitting, disseminating, storing or in
any other way dealing or acting in reliance on the information. If you
have received this email in error, we request you contact ABN AMRO Morgans
Limited immediately by returning the email to [EMAIL PROTECTED]
and destroy the original. We will refund any reasonable costs associated
with notifying ABN AMRO Morgans. This email is confidential and may contain
privileged client information. ABN AMRO Morgans has taken reasonable steps
to ensure the accuracy and integrity of all its communications, including
electronic communications, but accepts no liability for materials
transmitted. Materials may also be transmitted without the knowledge of ABN
AMRO Morgans. ABN AMRO Morgans Limited its directors and employees do not
accept liability for the results of any actions taken or not on the basis
of the information in this report. ABN AMRO Morgans Limited and its
associates hold or may hold securities in the companies/trusts mentioned
herein. Any recommendation is made on the basis of our research of the
investment and may not suit the specific requirements of clients.
Assessments of suitability to an individual's portfolio can only be made
after an examination of the particular client's investments, financial
circumstances and requirements.
****************************************************************************
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/
