i’m currently developin a sample app for my demo. i will be using quite a no of graphics. i was wondering, for the client development, the graphics will be stored with the client right?
in this case, can i read my map information from the server and sent to my client?
in the future if i want to add more features, it seems like i will need to constantly change/recode my client as well as the server components. is there a way where i can add in new features without changing my client?
In any design framework where you will store data ( such as image, music or other “heavy” objects ) on the client side, you will have the same issue of updating the client with new content as it becomes available. SGS doesn’t appear to handle that for you, but at the same time it shouldn’t make it any harder either.
There was another recent discussion about using WebStart “behind the scenes” to help manage automatic updating of clients that are not actually JWS applications ( at least not from the perspective of hte users ). I’m looking for the thread but someone else might beable to point you to it faster. It may be what you are looking for.
Our current idea for this is an embedded derby database client-side holding all static graphical data. An XML-document with the current version info is accessed from the same location the discovery.xml is loaded from and then a query to the local database is made to check what is needed for an update. Then this new data is requested from the web-server on the same location as the discovery.xml comes from and stored in the local database with a new timestemp. All details about what and where to load is given in this version info xml-document. Atleast this is our current idea how to implement this - all static graphical data is on the web-server outside of the SGS.
Ragosch
So in your model the client determines it has some out-of-date images based on the info on the server, downloads them automatically and stores them in the local database. The client also accesses all images from the database run-time. Is that a correct interpretation?
I was looking at using an imbedded derby for other stuff on the client side since it can be fairly well secured against alteration (nothing’s perfect, but it’s better than any home grown solution I’d produce). I hadn’t considered using that technique to secure and manage file resources as well, but it would be interresting to check it out.
Yes, the client requests all the changes since last login from the server after login has completed. A join-operation of these changes with those elements already stored in the local database is made and the intersection of both is loaded from the web-server and integrated into the local database in order to update it.
Actually we think of creating our own server-cluster software parallel to SGS and see how SGS will evolve. SGS seems to be good for all mud-like games which use a kind of room and items storage while it has a big downside when it comes to handle data which needs to be accessed via database queries or managed by a fast loading manager class which could provide the mass data as needed … currently with the SGS this class would need to be a GLO which needs to use external storage accessed via sockets in an asynchron manner … we doubt that this will be fast enough for our requirments and it fails where we need some synchron interaction of mass data with the SGS; there is no way to access any local serverside storage other than the objectStore in the SGS which is not suitable for huge data IMO.
Ragosch