Enterprise Project
About Enhydra Enterprise
Project Mail Lists
Working Groups
FAQs

Software
Downloads
Documentation
CVS Repositories
Roadmap
License

About Enhydra.org
Who We Are
News, Articles & Events
Getting Involved
Contact Us

Community
Demos
Contributions
Resources
Case Studies
On The Edge! -NEW-
Commercial Vendors

I understand your point. Without a solid set of supporting infrastructure,
creating high level integration models is problematic at best. Unfortunately
Enhydra has no control over how Macromedia extends the flash player. Flash
does have some rudimentary I/O functionality with the "FS command" (used to
pass JavaScript commands out of the flash player) and the "import/export
variables" command (basic get and post transfers). The problem with them is
the reliability and persistence of the connection. Flash has to deliberately
send out and listen for messages, which is far to rigid of a communication
system to create any sort of comprehensive interface. If anything is to be
done to improve/provide smooth and reliable communication between flash and
an app server then it must be ported through Flashes existing services. One
thought is to write a set of actionscript functions to manage an XML socket.
The XML socket object is new to Flash, and even by Macromedia's own
evaluation is difficult to set up and use effectively (read the XML socket
documentation in the actionscript help reference). Perhaps a solid set of
actionscript code could be included which facilitated and managed an XML
socket that passes XML-RPC commands and responses between Flash and a
management class inside of Enhydra. This would essentially open up a window
of communication that was not based on deliberate Flash events, but could
actually respond to and initiate server events. Things to consider are
security, performance, socket reliability, etc. Both the Enhydra and Flash
components of the socket manager would have to optionally support
encryption, persistence, connection monitoring and management, etc. The
installation options could be contained in a property sheet which a
developer could set at deployment time - similarly to how EJBs installation
options are configured via property sheets. The Enhydra extension could wrap
the connection and maintenance tasks up into one distributable package in
the form of:

1) An Enyhdra class to establish, maintain, monitor, and manage an XML
socket
2) An actionscript library that could be included into any Flash movie using
Flash 5's "include *.as" file command. The library would provided the Flash
side of the socket maintenance, monitoring, and management.
3) An XML property sheet used by both sides to establish the environment and
configuration variables.
4) Documentation on how to pass information back and forth over the socket.

This type of system would remove the need for Flash and application
developers to build complicated custom communication and security piping for
there specific application and allow them to focus on developing the
business logic and presentation layers of there app.

Jordan Duggan
Chief Creative Director
Indicium Design
Phone: 919.829.0650
Cell: 919.696.7936
Fax: 801.912.1503


-----Original Message-----
From: owner-Designers@enhydra.org [mailto:owner-Designers@enhydra.org]On
Behalf Of dlb
Sent: Monday, March 05, 2001 4:39 PM
To: Designers@enhydra.org
Subject: Re: Designers: Hello




> The larger problem, in my opinion, is a lack of a high
> level standard integration model. There is no standard method of
> communication between Flash and the application it is serving.

I agree with alot of what you're saying , but feel that fundamental problem
actually derives from the lack of a 'low level integration model'  ;) - ie.
File
I/O, an extension architecture - some way to extend the Flash player.  I'm
not
sure of what Enhydra can do in this area .

I'd asked this before - and am being a bit lazy in determining this for
myself ,
but when inquiring on Enhydra's emphasis on embedded devices someone had
mentioned that Enhydra had a 'small footprint'. What element of the Enhydra
platform is meant to be installed on embedded devices ?  I haven't come
across
anything in the materials so far which mentions a component for embedded
devices.

Am I misinterpreting this ?

D



----------------------------------------------------------------------------
-
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
with the text "unsubscribe designers" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-designers@enhydra.org.

-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
with the text "unsubscribe designers" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-designers@enhydra.org.