That statement about fds.swc certainly was true before, but the DataService apis are used to power the rpc based data tools in the new Flex Builder. In the beta at least, it was the exact same file shipped in LCDS as in FB, so presumably use of that file would be covered by the FB4 license. There's a public adapter interface in the code in which you can translate messages into whatever operation on the client. It is used as the hinge point that switches between "client DMS" in FB4 and LCDS. That would be the easiest way probably to hook into Granite - just use their client apis to emulate the LCDS behavior right there in a new extension of RPCDataServiceAdapter. Alternatively, you could override DataServiceAdapter's invoke method and translate them directly into granite's AS library calls.
With BlazeDS on the backend, you can use the standard DataServiceAdapter which sends those DataMessages to a new DataService on the server. There you would need some Java code to replace that DataService.java's "serviceMessage" (I think). It would translate those messages into the Assembler calls, then get the response and translate that data back into DataMessages. The hardest one is the "batch" message used for updates. It essentially means decoding a series of messages and making repeated calls to createItem, updateItem, etc. Even that is easy until you start to factor in associations. That requires some subtle logic for turning the ids into instances to preserve instance integrity but LCDS was not the first place I used those algorithms :) I think you also could get manual sync working using BlazeDS since the DataService just uses a normal Consumer for implementing that. Hopefully if the new DataService extends MessagingService that would just work but there is probably some tweaking needed there. I have a feeling the farata folks might have some of these pieces already so maybe we can just contribute to that project? FB4 also contains the core Java modeling code, used to generate those service wrapper classes on the client. FB4 does not contain the tools to generate those models other than against simple RPC backends. If the dev license for LCDS really is free though, I wonder if you could use it to generate models that you deploy on other servers? If so, with a bit more work you could write a model adapter which generates JPA code. Not too hard if you do not mind a web-app restart for model changes. To me Adobe should be a tools company... giving the tools away for free seems like a bad strategy. Jeff On Fri, Jan 22, 2010 at 10:05 AM, busitech <[email protected]>wrote: > > > Good to hear from you, Jeff! We are saddened too. We are quite passionate > about LCDS, and always have been. We built somewhere in the neighborhood of > 14 test cases for LCDS 3.0 during the most recent alpha/beta, so just in the > last 6 months our investment has remained quite significant even though > we're a small company without deep pockets. This was not welcome news to say > the least, especially at the end of the beta process we just went through, > upgrading everything. I feel like the crew of the SS Minnow! Here's what the > developer of another Flex data project has said about fds.swc: > > [Our] data management implementation is quite different than the one in > LCDS. The code and APIs from LCDS have not been ported. The reason for that > is Adobe's license agreement. When you use Adobe's LCDS approach, your > client code is coupled to their library (fds.swc). Even if you do not have > LCDS running on the backend, but use their client-side data management > library, you still owe the LCDS licensing fee to Adobe. Our attorney > confirmed this and we also had a conversation with the LCDS team management > about it as well. > > > Our software uses the LCDS exclusive features quite heavily, especially for > sending messages from server to client. We have an ERP system almost ready > to release. If an inventory count changes, it is broadcast in case anyone is > selling from an inventory search which has become stale. Price changes work > the same way, as well as customer A/R balances, etc. > > We will be looking at how to recreate the auto sync functions and obtaining > true data push (or reverse RPC). We're looking at > Red5<http://code.google.com/p/red5/> > for possibly adding RTMP to BlazeDS. At least if we start with BlazeDS, we > can use our custom object proxies in the serialization process. Red5 has > also implemented SharedObjects (between client and server) which is really > neat. > > I will definitely read your articles. Unless Adobe hurries up and changes > their LCDS licensing policies very soon, I'll be interested in working on a > project which would at least integrate what is available, and build the > missing pieces. > > Some of the client code found in fds.swc has been recreated by Farata > Systems and released as open > source<http://sourceforge.net/projects/cleartoolkit/>. > They've built change tracking/logging on the client for sending and array of > ChangeObjects to the server through a RemoteObject, simulating what LCDS > would pass to the sync() method... I have not looked at their > OfflineDataCollection yet. I don't think they've got unsolicited data push > in there, but I'm still investigating. They've also got an NIO streaming AMF > channel endpoint written for BlazeDS on Servlet 3.0. > > Thank you for your willingness to contribute, Jeff. Let's watch this thread > to see what kind of demand there is. We may need to move on it simply for > our own product to be marketable. > > Best Regards! > > >
