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!
