João, What you are trying to do is a perfect use of Red5. And yes it's stable enough to work with for things like this. In fact the idea of keeping objects in sync on the client with what is on the server side is something that Luke and I have discussed and certainly something we would like to develop at some point in the future. The Flex data service thing that Adobe sells does this type of thing, but requires you to use their proprietary software, and you don't get the really great API that Red5 has, not to mention the easy integration with other APIs like Hibernate.
Anyway, this client side syncing library is certainly something that would be useful to everyone. I'm hoping to develop it in AS3, but an AS2 version would be excellent as well. Please let us know how you come along with this. I still think that it would be wise for you to take smaller steps such as I mentioned before. Like get Red5 and Hibernate hooked up to your application with AMF first. This wouldn't require any changes at all on your client for that. Then once you have that down, your server side piece is nearly finished and you will then be able to focus on the notifications and modifying your client to use a NetStream connection. Just my two cents. I hope it helps. -Chris On 10/12/06, João Saleiro <[EMAIL PROTECTED]> wrote: > > Hi Chris, > > what i currently want to do is to step-by-step enhance the current > framework. There are two different kind of improvements: adding > functionality to it, and applying Agile techniques to fasten up code > writing. > In a long term (may be utopia...), i wish to have a framework supporting > full data synchronization with the server, video streaming and recording, > but also less and better code, created via UML and automatic code generation > techniques. What would be perfect for me was to have a RIA like > CastingOffice with the data synchronized between all the clients and the > server, but spending time only coding the database, business rules when they > apply, and the interface. > For the database, I am currently trying db4o. ODBMS is something that i > find interesting and i guess in a near future RDMBS will be replaced for > ODBMS. > Yeah, i know i have hard-work to do, and the worse is that i'm doing it in > on my spare time, so it will take toooo long to see this finished, if it > will ever be... > > >You probably will find that it is overkill to have your > >entire application using this type of connection. > > > One of my major worries, is to know if what i want (the synchronization) is > currently possible. I have something in mind (needs to be polished), and > it's a bit difficult for me to explain in English, but i'll try. > > When coding client-server architectures, we want to abstract the fact that > we have a connection to the server. What would be perfect, was if the client > was using the data directly from a local database, and when the data > changes, the database would notify the views that registered for that data. > Currently we have something very similar to this: we have the data on the > server, and we have a small replication on the client (on the ModelLocator). > When the view needs some data, it calls a command (etc, etc), that retrieves > the data from the server and puts it on the ModelLocator. Then the > ModelLocator dispatches and event alerting the views that registered for > that data to refresh the screen. > > But we have two major problems: > > 1- If a user opens a view that needs data, this data is loaded from the > server. The second time the user opens the view we have to load the data > again. We could use the existing data on the client, but we do not know if > it was changed on the server, so it's better to request a new copy. If there > weren't alterations, we are making an useless request. > > 2- If we have two clients using the application, imagine that the first > adds a new Person to the database. The second needs to refresh the screen to > know that there is a new Person. But he doesn't know that there are changes, > so why would he refresh the screen? On CastingOffice, we solved this by > pooling data from the server time to time. Every request has a times tamp, > so the server only retrieves the changes. But either way, we are making a > lot of useless requests. > > I have in mind to extend the framework so that when a view registers for > changes on the Model (and here the model would have exactly the same > structure as the database), the Model also registers with the server for > changes on that model (and retrieves the data on the registration procedure, > of course). This way, whenever the model changes on the server, it would > alert all the clients that registered for that data that there are changes. > To know when the model changes is quite simple, but my solution still > doesn't seem very elegant to me: on the commands that can make changes on a > particular model, we call the synchronizer to check which clients registered > for that data, and alert them for changes. > On an application like CastingOffice, where at the end we will have about > 60 tables (and a lot of relations between them, that's why i want to use > ODBMS, but that's another history :P), we have a lot of data to synchronize, > of course. But the clients register only for changes on the data currently > on the screen (i mean, on the current view). If the user moves to another > screen, the previous unregisters all the models that it needs, and the new > one register the new models. > > The concept seems quite simple to me (but i imagine that there are better > solutions out there....), but what worries me most is how to implement it > with Red5 with so little spare time, and to know if my idea is doable with > Red5, without performance issues. Of course if this reveals to be possible, > i will need some weeks to put it working. But i want to be sure that it's > worth taking this effort. > > Do you think it's a good idea? And do you think it will work fine with Red5 > (performance issues, limitations, etc)? Are there better solutions? > > Uff... my mails are always so big :| > > Chris, obrigado eu pela sua ajuda! :) Espero que tenha passado uma > excelente lua de mel! ;) > > Cumprimentos, > > João Saleiro > > > > > > > > > > > > > João Saleiro > > > > > Email/MSN: [EMAIL PROTECTED] > Skype: joao.saleiro > Tel: +351 916 077 097 / +351 968 203 370 > WWW: http://www.webfuel.pt > > > > Chris Allen wrote: > João, > > There is nothing wrong with switching over to Red5 for the server side > logic of your application. Since you are hoping to code in Java, > utilize Hibernate and take advantage of the RTMP connection, it seems > to make logical sense. > > So, with this in mind, I would look at switching your existing > application to use AMF and Red5 first, as your current version is > using the AMF protocol to talk with PHP. AMF0 is fully supported and > this is the only one that works with AS2 anyway. Simply switch the > server side logic to use Hibernate and Red5. Once you get that going > then switching to a notification type setup over RTMP would be a good > next step. You probably will find that it is overkill to have your > entire application using this type of connection. AMF may be perfectly > fine for most of the calls. Just add RTMP shared objects where they > make sense. > > Now, in terms of where to go for resources, there are a bunch of > examples included with the server. Also, as you have seen, someone > recently posted an example of Red5 using AMF and Hibernate. That's the > one that I would use as a starting point if I were you. > > Obrigado para tentando usar O Red5, é boa sorte! (Man, never seen so > much Portuguese being used on this list before) :-D > > -Chris > > On 10/12/06, João Saleiro <[EMAIL PROTECTED]> wrote: > > > Olá Zé, > > great, but i do not intend to use AS3 right now. My intentions are to > start looking to AS3 by the end of November, but currently i have to > finish this application on AS2 and it's out of question changing to AS3. > Well, it's also out of question to use Red5, but since i'm trying it on > the spare time, if i can make the transition we all will win :). But > what's the problem of applying this feature using Red5? > > Thanks, > > João Saleiro > > > > João Fernandes wrote: > > > Bom dia João, > > There is already a solution for what you're looking for. It's called Flex > Data Services which synchs automatically all clients connected to a > destination. > RPC calls are still available in FDS but Data Services is what you're > looking for. > > João Fernandes > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of João Saleiro > Sent: quinta-feira, 12 de Outubro de 2006 11:20 > To: [email protected] > Subject: Re: [Red5] Migrating from AMFPHP to Red5 > > Michael, > > I want to kill php code :). > I will try to use db4o (an ODBMS) with red5, as an experience to improve > the current framework. :) > So I have to say bye bye PHP. And what i want with red5 is to say also > "bye bye refresh button". > > Do you have any recommendations that could help me? (see my previous mail). > > João Saleiro > > > Michael Klishin wrote: > > > > On Thursday 12 October 2006 07:18, João Saleiro wrote: > > > > > > My biggest problem right now is to find how to give the server > initiative to alert all the clients, and how to adapt the client-side > code to work with Red5 and the synchronization features, changing it as > less as possible. Any advices to help me starting with this? > > > > Joao, > > First off, think whether you REALLY need to use something but SO if you > > > have > > > > AMF calls working right with AMFPHP? You can access database from Red5 > > > apps > > > > as long as Spring integrates with Hibernate like a charm (including > transactions stuff) so you can just ADD Red5 to your legacy application, > powered by php. > > You can use sockets for this, that's the way I connected Red5 with Rails > application. Or just share the same database. > > AMF3 support in Red5 is still incomplete... > > Regards, > > > > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > > > _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
