Re: Improvements on SmartFrog

Gustavo Mendes wrote:
> Hello Steve, How are you?

I'm good.

> Perhaps the problem is not only the messages that are displayed, but
> also the way they are formatted. Perhaps if the error message was
> showed like that: [Error Message: The attribute "xyz" in the component
> "wz" is not being referenced on the correct way in component "z"] was
> more intuitive to system administrators. Perhaps the messages that are
> showed today is more intuitive for programmers, technicians on the
> computer science area. From now, we will police ourselves to error
> messages and feedback you (the SmartFrog team).
> 


good error messages are important; I'd cite XML parsers as a classic 
area for improvement there.


>>>      - Build.xml file: We think that the build.xml that is
>>>distributed with SmartFrog is extremely dependent on the SmartFrog
>>>directories hierarchy. For example, if a developer want to develop a
>>>new component in SmartFrog, the easiest way is creating a subdirectory
>>>in $SMARTFROG/examples/ to use the build.xml to build his project. We
>>>think that via the Eclipse plugin or via a new build.xml for
>>>developers/administrators is a good idea.
>>
>>which build.xml are you using?
> 
> 
> $SMARTFROG/build.xml
> 
> 
>>We have been reworking the build file(s), so that you build components
>>in a separate tree, called components,
>>Each component lives in a separate source tree, and can have its own
>>unit test suite. We also have a set of Ant tasks to deploy, undeploy and
>>control SmartFrog daemons as part of the source process. The build files
>>related to this should be a foundation to do stuff outside the main
>>source tree -you just need to set a few properties to point to where the
>>core directory tree is to aid integration.
>>
> 
> Great!

You should get into CVS and look at how we do components now; all off 
the main build tree.

> 
> 
>>Even so, I will have to be the first to point out that the build process
>>is complex. One of my colleagues, Kumar, has been busy improving the
>>build process for doing product releases, and he has added a lot of
>>stuff, such as forrest-based documentation. With all this stuff in place
>>you *can* do standalone component development, with integrated
>>deployment. One of the components we have is a JUnit component, which
>>could act as a foundation for integrating testing with deployment. We
>>need to work in this more, but it should start.
> 
> 
> This will help us enormously.
> 

> Not yet. We will develop some components that will help the system
> administrator to deal with services and data from april. We are
> interested on the way that SmartFrog deal with distributed
> communication (currently via RMI) and the CDDLM language. About that,
> how is the work on SOAP/webservices and CDDLM notation as XML?

Well, we are torn between writing an XML version of the language, or 
changing XML2.0 to be more like SmartFrog :)

Let's just say the standards work progresses, new drafts of the specs 
come out this week.

However, once you are in standards work
  -there is pressure to adhere to all the other bits of the grand 
architecture, in this case the WS-RF resource framework, WSDM for 
management, XSD for a type language, and so on.
  -the specifications come before the implementation, which is the 
classic waterfall design that everbody knows doesnt work.

There is currently in CVS (core/components/CDDLM) an implementation of 
the initial SOAP deployment API, and a component that deploys Axis 
endpoints. This gives you a SOAP deployment API for long-haul 
deployment, without having to depend on WSRF or the rest of the 
specification. Once we have finished the next set of drafts, I will 
start on implementing the XML language.  I am going to be honest though, 
in exchange for the integration with the rest of the XML infrastructure, 
you are going to have a language that is not going to be that easy to 
work with. Similarly, the new SOAP API will be hard to work with without 
WSRF extensions to your soap stacks. Don't hold your breath for all of 
this. Plus of course there is all the security stuff you suddenly have 
to deal with...

On the subject of long-haul deployment, I am thinking of a component 
"RemoteUpload", that will let you upload files to a remote location and 
return a file path and URL to them. This would be usable by client apps 
to get files up to remote systems over the secure RMI channel, then get 
a path that can be used elsewhere in their deployments.

Anyone done something like this already?

-steve



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click