amis-devl — AMIS development list

Re: [Amis-devl] Web site address for a multi lingual Indian language speech synthesizer

[Pranav L. <no...@vs...>]

Hi all,
<snip Porting web applications to exist only on a single client could get 
ugly so for a PC interface I think we should pursue a standard GUI.

PL] Agreed. The gui would have to be platform specific for example, on 
linux one would use gnome with its screen reader while on windows, one 
would probably use a Microsoft based gui since it is the most accessible.

Pranav

Re: [Amis-devl] Web site address for a multi lingual Indian language speech synthesizer

[Marisa D. <ma...@di...>]

Hi,

That is very interesting, we should keep it in mind.  Free Java TTS has 
a ways to go, hopefully their project can help move it along.

Dinesh, what TTS does Safa use for Hindi? Have you ever used the Dvhani 
TTS [1] ?

I think a web-based Amis is a great idea for one of several interfaces. 
  Why not have an online version - is this possible?

Porting web applications to exist only on a single client could get ugly 
so for a PC interface I think we should pursue a standard GUI.

Ideas anyone?

marisa

[1]: http://dhvani.sourceforge.net/

on 10/29/2003 12:32 AM HP Kotian wrote:
>    
> Hello Merisa
>  
> I am attaching a web page which gives info on the captioned subject. 
> Besides, there is a link for a java based speech synthesizer in english.
>  
> I suppose this would fascilitate developing Amis Next using a web 
> browser based interface.
>  
> Please comment
> Harish

[Amis-devl] [Fwd: project guidelines]

[Marisa D. <ma...@di...>]

 From Dinesh:
--
Hi all,
Following is the information about The xml.apache.org Project Guidelines,
which may be consulted for formulating the project guidelines for AMIS next
project.

available at
http://xml.apache.org/guidelines.html

it includes topics like



List of 6 items
. Roles and Responsibilities
Defines the recognized roles in the project.
. Communication
Defines how users and developers communicate.
. Decision Making
Defines how action items are proposed and voted on.
. Source Repositories
Defines how the Project's source code is organized and developed.
. Project Management
Defines the roles and responsibilities of the Project Management Committee
(PMC).
. Our Mission / Charter
A copy of the Charter document for the xml.apache.org Project.
list end
regards
Dinesh

Re: [Amis-devl] site blog

[Marisa D. <ma...@di...>]

Hi,

It was requested at the bangkok workshop that we have a way to post to a 
webpage in order to log useful online resources.  I think it definitely 
shouldn't be used for having discussions, the mailing list is best for that.

Do you think that is a good idea?

marisa

on 10/29/2003 12:38 AM HP Kotian wrote:
> Dear Merisa
> 
> Does it really give it any significant edge? Can we not continue here?
> 
> Harish
> 
>  ----- Original Message ----- 
> From: "Marisa DeMeglio" <ma...@di...>
> To: <ami...@li...>
> Sent: Tuesday, October 28, 2003 8:51 PM
> Subject: Re: [Amis-devl] site blog
> 
> 
> 
>>Hi,
>>
>>You type your main text in the third text field on the screen.  The 
>>Title field is for the name of your post, and the URL field is for 
>>typing a URL if your post is about a certain page.
>>
>>When you're done, then select "Post & Publish" (you should be able to 
>>TAB over to it).
>>
>>Or you can hit Control + Enter to "Post" but not publish (publishing 
>>adds your entry to the publicly viewable webpages).  Then to publish, 
>>you have to find the "PUBLISH" button (you can TAB to it, it's a few 
>>controls after the text entry fields).
>>
>>Blogger.com stupidly has not made keyboard shortcuts for everything.
>>
>>Regarding the whole page, here is the layout I see:
>>
>>Top half of the screen:
>>
>>Top of page: Blogger logo
>>Series of toolbar controls: Upload file, spellcheck, hyperlink, bold, 
>>italic, post, post & publish
>>
>>Text fields: Title (cursor starts here by default), URL, Body of post
>>
>>Graphic link: small arrow which hides or shows the side bar with two 
>>checkboxes.  by default this sidebar is shown.
>>
>>Checkboxes: Draft, Change time and date
>>
>>Bottom half of screen:
>>
>>Three tabs which do not seem very accessible ("Posts" (active tab), 
>>"view blog", "publishing")
>>
>>let me know if you run into any difficulties
>>
>>marisa
>>
>>on 10/28/2003 9:38 AM Pranav Lal wrote:
>>
>>
>>>Hi,
>>>
>>>I am a shade confused about the blog's posting interface. I get to the 
>>>window where the title has to be given and there is an URL and a 
>>>checkbox that allows one to mark one's post as a draft. Do I type my 
>>>message there? Those edit boxes don't seem to be properly labeled.
>>>
>>>Pranav
>>>At 06:51 PM 10/28/2003 Marisa DeMeglio wrote:
>>>blog
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: SF.net Giveback Program.
>>>Does SourceForge.net help you be more productive?  Does it
>>>help you create better code?   SHARE THE LOVE, and help us help
>>>YOU!  Click Here: http://sourceforge.net/donate/
>>>_______________________________________________
>>>Amis-devl mailing list
>>>Ami...@li...
>>>https://lists.sourceforge.net/lists/listinfo/amis-devl
>>>
>>>
>>
>>-- 
>>Marisa DeMeglio
>>ma...@di...
>>AMIS Development Coordinator
>>http://www.amisproject.org
>>http://amis.sourceforge.net
>>DAISY For All Project (DFA)
>>
>>

Re: [Amis-devl] site blog

[HP K. <hpk...@rb...>]

Dear Merisa

Does it really give it any significant edge? Can we not continue here?

Harish

 ----- Original Message ----- 
From: "Marisa DeMeglio" <ma...@di...>
To: <ami...@li...>
Sent: Tuesday, October 28, 2003 8:51 PM
Subject: Re: [Amis-devl] site blog


> Hi,
> 
> You type your main text in the third text field on the screen.  The 
> Title field is for the name of your post, and the URL field is for 
> typing a URL if your post is about a certain page.
> 
> When you're done, then select "Post & Publish" (you should be able to 
> TAB over to it).
> 
> Or you can hit Control + Enter to "Post" but not publish (publishing 
> adds your entry to the publicly viewable webpages).  Then to publish, 
> you have to find the "PUBLISH" button (you can TAB to it, it's a few 
> controls after the text entry fields).
> 
> Blogger.com stupidly has not made keyboard shortcuts for everything.
> 
> Regarding the whole page, here is the layout I see:
> 
> Top half of the screen:
> 
> Top of page: Blogger logo
> Series of toolbar controls: Upload file, spellcheck, hyperlink, bold, 
> italic, post, post & publish
> 
> Text fields: Title (cursor starts here by default), URL, Body of post
> 
> Graphic link: small arrow which hides or shows the side bar with two 
> checkboxes.  by default this sidebar is shown.
> 
> Checkboxes: Draft, Change time and date
> 
> Bottom half of screen:
> 
> Three tabs which do not seem very accessible ("Posts" (active tab), 
> "view blog", "publishing")
> 
> let me know if you run into any difficulties
> 
> marisa
> 
> on 10/28/2003 9:38 AM Pranav Lal wrote:
> 
> > Hi,
> > 
> > I am a shade confused about the blog's posting interface. I get to the 
> > window where the title has to be given and there is an URL and a 
> > checkbox that allows one to mark one's post as a draft. Do I type my 
> > message there? Those edit boxes don't seem to be properly labeled.
> > 
> > Pranav
> > At 06:51 PM 10/28/2003 Marisa DeMeglio wrote:
> > blog
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?   SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Amis-devl mailing list
> > Ami...@li...
> > https://lists.sourceforge.net/lists/listinfo/amis-devl
> > 
> > 
> 
> -- 
> Marisa DeMeglio
> ma...@di...
> AMIS Development Coordinator
> http://www.amisproject.org
> http://amis.sourceforge.net
> DAISY For All Project (DFA)
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Amis-devl mailing list
> Ami...@li...
> https://lists.sourceforge.net/lists/listinfo/amis-devl

[Amis-devl] [Fwd: Re: [#16722] Accessibility of posting interface]

[Marisa D. <ma...@di...>]

Below is my reply from blogger.com

-------- Original Message --------
Subject: 	Re: [#16722] Accessibility of posting interface
Date: 	Tue, 28 Oct 2003 12:01:41 -0800
From: 	Blogger Support <bl...@tr...>
To: 	marisa demeglio (1878254, ) <mar...@ya...>



Hi Marisa,

Thanks for writing in, this is definitely something we need to improve in
Blogger. I've passed your note on to our team and hopefully this will
happen soon.

Good luck with your current project, and please let us know if there's any
way we can be of further assistance!
-Eric,
Blogger Support



Original Message Follows:
------------------------
From: "marisa demeglio (1878254, )" <mar...@ya...>
Subject: Accessibility of posting interface
Date: Tue, 28 Oct 2003 07:27:55 -0800

Dear Blogger,

I recently created a multiuser blog for a project I am working on.  Many
of my colleagues are blind and use screen readers or talking web browsers.

We have found some accessibility issues in your site:

1.  There aren't keyboard shortcuts for everything (eg, "Post" = ctrl +
enter, but nothing for "Post & Publish")
2.  Tabs aren't accessible 
3.  Text input fields not well labeled
4.  "Blog this!" toolbar is not accessible (can't TAB to it)

My colleagues are expert computer users and these are the problems they
face.  I imagine everyday blind users have even more difficulty.

It would be great if you could make the small changes necessary to your
site to allow our team to use it fully.  

Thank you,

Marisa

[Amis-devl] accessibility request sent to Blogger

[Marisa D. <ma...@di...>]

I have sent this to Blogger.com in hopes that they will make some 
improvements.  If you find more things or want to comment, please let 
them know at http://new.blogger.com/user_problem_new.pyra.

<snip>
Dear Blogger,

I recently created a multiuser blog for a project I am working on.  Many 
of my colleagues are blind and use screen readers or talking web browsers.

We have found some accessibility issues in your site:

1.  There aren't keyboard shortcuts for everything (eg, "Post" = ctrl + 
enter, but nothing for "Post & Publish")
2.  Tabs aren't accessible
3.  Text input fields not well labeled
4.  "Blog this!" toolbar is not accessible (can't TAB to it)

My colleagues are expert computer users and these are the problems they 
face.  I imagine everyday blind users have even more difficulty.

It would be great if you could make the small changes necessary to your 
site to allow our team to use it fully.

Thank you,

Marisa
</snip>

Re: [Amis-devl] site blog

[Marisa D. <ma...@di...>]

Hi,

You type your main text in the third text field on the screen.  The 
Title field is for the name of your post, and the URL field is for 
typing a URL if your post is about a certain page.

When you're done, then select "Post & Publish" (you should be able to 
TAB over to it).

Or you can hit Control + Enter to "Post" but not publish (publishing 
adds your entry to the publicly viewable webpages).  Then to publish, 
you have to find the "PUBLISH" button (you can TAB to it, it's a few 
controls after the text entry fields).

Blogger.com stupidly has not made keyboard shortcuts for everything.

Regarding the whole page, here is the layout I see:

Top half of the screen:

Top of page: Blogger logo
Series of toolbar controls: Upload file, spellcheck, hyperlink, bold, 
italic, post, post & publish

Text fields: Title (cursor starts here by default), URL, Body of post

Graphic link: small arrow which hides or shows the side bar with two 
checkboxes.  by default this sidebar is shown.

Checkboxes: Draft, Change time and date

Bottom half of screen:

Three tabs which do not seem very accessible ("Posts" (active tab), 
"view blog", "publishing")

let me know if you run into any difficulties

marisa

on 10/28/2003 9:38 AM Pranav Lal wrote:

> Hi,
> 
> I am a shade confused about the blog's posting interface. I get to the 
> window where the title has to be given and there is an URL and a 
> checkbox that allows one to mark one's post as a draft. Do I type my 
> message there? Those edit boxes don't seem to be properly labeled.
> 
> Pranav
> At 06:51 PM 10/28/2003 Marisa DeMeglio wrote:
> blog
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Amis-devl mailing list
> Ami...@li...
> https://lists.sourceforge.net/lists/listinfo/amis-devl
> 
> 

-- 
Marisa DeMeglio
ma...@di...
AMIS Development Coordinator
http://www.amisproject.org
http://amis.sourceforge.net
DAISY For All Project (DFA)

Re: [Amis-devl] site blog

[Pranav L. <no...@vs...>]

Hi,

I am a shade confused about the blog's posting interface. I get to the 
window where the title has to be given and there is an URL and a checkbox 
that allows one to mark one's post as a draft. Do I type my message there? 
Those edit boxes don't seem to be properly labeled.

Pranav
At 06:51 PM 10/28/2003 Marisa DeMeglio wrote:
blog 

[Amis-devl] site blog

[Marisa D. <ma...@di...>]

Hi all,

As requested in Bangkok, there's now a blog for posting about accessible 
development resources.

The webaddress is: http://amis.sourceforge.net/blog/
I'll do a nice visual layout soon, but the page elements won't change.

the interface is through blogger.com

If you haven't already seen it, bookmark the "BlogThis!" link on 
blogger.com's homepage.  When you select the bookmark, it brings up a 
window that has a blog posting form, automatically filled in with the 
URL and title of your current webpage.  It's a fast way to post.

if you would like to become a blog member, send me the email address you 
want to be subscribed under.

-marisa

Re: [Amis-devl] soap

[Pranav L. <no...@vs...>]

Dinesh,
<snip one can use
webservices for discovery and invocation, but do we need that much elaborate
mechanism for object on the same machine?

PL] An excellent point. SOAP seems to be designed to work across a 
distributed system. One can get it to work on a single system but seems to 
be an overkill at this point. As for object discovery., I am not sure that 
we require that since the objects will be known.

Manish, any comments?

Pranav

[Amis-devl] soap

[Dinesh K. <din...@ho...>]

another article on SOAP.

What I have understood, is that soap, facilitate object communication, but
there is no mechanism for discovery and invocation of objects. one can use
webservices for discovery and invocation, but do we need that much elaborate
mechanism for object on the same machine?

regards
Dinesh



This article assumes you're familiar with COM, XML, JScript
Download the code
(9KB)

SOAP: The Simple Object Access Protocol
Aaron Skonnard

Remote objects can give a program almost unlimited power over the Internet,
but most firewalls block non-HTTP requests. SOAP, an XML-based protocol,
gets
around this limitation to provide intraprocess communication across
machines.

Developers have a hard time agreeing on anything. They are fiercely loyal to
the technologies they use and they don't like to compromise by adding
support
for the other guy's technology. Long and bitter technical wars have ensued,
leaving interoperability the victim. See Don Box's recent article, "
Lessons from the Component Wars: An XML Manifesto"
for another perspective on the problem.
For the most part, software component developers from opposite sides of the
tracks stay as far away from each other's technology as possible. This
polarity
makes it difficult to achieve any level of interoperability. It would be
great to find a component technology standard that everyone could agree on.
It
could be that a subset of minimal technologies is the best answer to this
quandary.
XML and HTTP are two such minimal technologies. The Simple Object Access
Protocol (SOAP) defines the use of XML and HTTP to access services, objects,
and
servers in a platform-independent manner. SOAP is a protocol that acts as
the glue between heterogeneous software components. If developer can agree
on
HTTP and XML, SOAP offers a mechanism for bridging competing technologies in
a standard way. The main goal of SOAP is to facilitate interoperability.
The industry has accepted HTTP. It's used everywhere, on all platforms. XML
is becoming as ubiquitous as HTTP. Today you can find an XML processor for
just
about any common platform or language. This ubiquity makes HTTP a good
choice for an interoperable transport mechanism.
XML is a simple and extensible text markup language. Because XML is just
text, any application can understand it as long as the app understands the
character
encoding in use. By default, XML assumes that all characters belong to
ISO/IEC 10646, known as the Universal Character Set (UCS). The XML
specification
(
http://www.w3.org/XML/)
mandates that all XML processors must accept character data encoded using
the UCS Transformation Formats UTF-8 or UTF-16. Therefore, any XML data
stream
encoded in UTF-8 or UTF-16 can be understood regardless of platform or
programming language. (Note that since the first 256 character codes of
UTF-8 match
up with ASCII, a UTF-8-capable processor can understand straight ASCII text
files. This makes XML a good choice for describing method invocations in a
platform and language-neutral fashion.
Combining HTTP and XML into a single solution gives you a whole new level of
interoperability. For example, lathered with SOAP, clients written in
Microsoft®
Visual Basic® can easily invoke CORBA services running on UNIX boxes,
JavaScript clients can easily invoke code running on the mainframe, and
Macintosh
clients can start invoking Perl objects running on Linux. The list goes on.
While some interoperability is achieved today through cross-platform bridges
for specific technologies, once SOAP becomes standard, bridges will no
longer be necessary.
As you'll see, much of what SOAP represents is simple, and it's nothing new.
SOAP simply codifies existing practices into an industry standard from which
everyone can benefit.

Firewall Woes
Currently, developers struggle to make their distributed applications work
across the Internet when firewalls get in the way. Since most firewalls
block
all but a few ports, such as the standard HTTP port 80, all of today's
distributed object protocols like DCOM suffer because they rely on
dynamically assigned
ports for remote method invocations. If you can persuade your system
administrator to open a range of ports through the firewall, you may be able
to get
around this problem as long as the ports used by the distributed object
protocol are included.
To make matters worse, clients of your distributed application that lie
behind another corporate firewall suffer the same problems. If they don't
configure
their firewall to open the same port, they won't be able to use your
application. Making clients reconfigure their firewalls to accomodate your
application
is just not practical.
Since SOAP relies on HTTP as the transport mechanism, and most firewalls
allow HTTP to pass through, you'll have no problem invoking SOAP endpoints
from
either side of a firewall. Don't forget that SOAP makes it possible for
system administrators to configure firewalls to selectively block out SOAP
requests
using SOAP-specific HTTP headers.

SOAP-like Technologies
DCOM-savvy developers will recognize that SOAP is similar to COM Internet
Services (CIS). CIS makes it possible to use DCOM in concert with HTTP (on
port
80). CIS uses a special HTTP-based handshake to establish the initial
connection between the client and server. From that point on, CIS relies on
DCOM
over TCP. While CIS does solve the firewall problem, it's a
platform-specific solution. CIS only works on certain Windows®-based systems
with the appropriate
CIS infrastructure in place (such as Internet Information Service (IIS), a
special ISAPI DLL, and special DCOM configuration settings). CIS makes no
attempt
to improve interoperability over the Internet.
SOAP is also similar to the Remote Data Services (RDS) DataSpace object,
which makes it possible to instantiate custom business objects on remote
servers
over HTTP. The following Visual Basic code illustrates how to create the
Lib.BusinessObj object on the server identified by http://skonnard.com:


Dim rdsDS as new RDS.DataSpace

set bo = rdsDS.CreateObject("Lib.BusinessObj", "http://skonnard.com")
result = bo.SomeMethod("Hello World")

Like CIS, the object creation and method invocation happen over HTTP, making
it possible for DCOM to get through the firewall. But like CIS, this
solution
is platform-specific, and the server also relies on an ISAPI DLL running on
IIS. All business components that you want to expose through this mechanism
must be configured differently in the registry than the way a standard DCOM
component is registered. Furthermore, the client must have the appropriate
RDS infrastructure in place for this communication link to work properly.
Remote scripting is another technology that makes it possible to call
server-side script functions directly from a browser's client-side script
over HTTP.
Microsoft implements remote scripting through a Java applet that runs in
either Netscape Navigator or Microsoft Internet Explorer. Once you have the
remote
scripting runtime files configured properly on your Web server and within
your client-side HTML files, you can start calling functions that live in
your
server-side ASP pages directly from DHTML. The following snippet illustrates
some client-side JScript code that gets called in response to a button's
onclick
event:


function button_onclick() {
var obj = RSGetASPObject("http://skonnard.com/myfunctions.asp");
var result = obj.SomeMethod("Hello World");
}

You can think of the ASP file as the class, and RSGetASPObject as a special
type of moniker that binds you to the class (similar to CoCreateInstance).
If
you think about it, this is just another way to call methods over HTTP.
Although this technology works from within different scripting languages on
the
client, it's tied to ASP and IIS on the server.
And finally, even the most basic Visual Basic WebClasses or custom ASP pages
are similar to SOAP. Both of these technologies make it possible to call
server-side
business objects over HTTP. For example, the following ASP page (which is
similar to the functionality of a WebClass-generated ASP file) creates an
instance
of the Lib.BusinessObj component and invokes SomeMethod, passing the string
sent by the client:


<%
set obj = Server.CreateObject("Lib.BusinessObj")
obj.SomeMethod Request.QueryString("param1")
%>

Simply sending an HTTP request for the given ASP page makes it possible to
invoke SomeMethod remotely. A client would invoke SomeMethod using the
following
URL:


http://skonnard.com/soaplike/businessobj.asp?param1=hello+world

At first, technologies like CIS, RDS, and Remote Scripting seem to resemble
SOAP, but this last example is actually a closer fit. Since ASP pages are
called
via HTTP, any client application capable of sending HTTP requests can invoke
SomeMethod on Lib.BusinessObj regardless of platform or language. Similarly,
if you write a Perl CGI script that happens to call a Perl object, any HTTP
client capable of requesting the CGI script can also indirectly invoke the
Perl object.
As you can see, SOAP is not an entirely new concept. I've described several
similar technologies available on the Windows platform today. SOAP attempts
to codify the main concept behind these existing practices into a simple and
generic protocol that can serve as an industry standard.

SOAP Requests
Imagine a component that lives somewhere on the Internet that implements the
PurchaseBook method on the purchase_book interface. This method would be
invoked
for a user to purchase a book from an online bookstore. The following HTTP
request represents how you would invoke such a method using the SOAP
protocol:


POST /cgi-bin/purchase-book.cgi HTTP/1.1
MethodName: PurchaseBook
InterfaceName: soap:cdl:com.develop.demos.purchase_book
MessageType: Call
Content-Type: text/xml-SOAP

<PurchaseBook>
<ISBN>0201379368</ISBN>
</PurchaseBook>

This HTTP request points to a uniform resource identifier (URI) of
/cgi-bin/purchase-book.cgi. Since the SOAP specification says nothing about
how a component
is activated, it's up to the code behind this URI to decide how to activate
the component and invoke the specified method.

SOAP HTTP Headers
You may have noticed that the Content-Type header uses a value of
text/xml-SOAP. SOAP defines this value to identify an HTTP entity-body
containing an XML-encoded
method invocation or response. All SOAP requests and responses must use this
Content-Type value to be recognized.
SOAP defines three extended HTTP headers. Two of these headers, MessageType
and MethodName, must be used with every SOAP request. The third header,
InterfaceName,
is optional. The MessageType header defines whether the given HTTP body
contains a method call or a method response and must contain the values Call
or
CallResponse, respectively. The MethodName header defines the name of the
method to invoke. The optional InterfaceName header defines the name of the
interface
to which MethodName belongs.
Because of HTTP's extensibility characteristics, you can create custom
headers for application-specific purposes without any problem. But it is
possible
that other applications may decide that a MethodName header is exactly what
they need for their application-specific purpose. Like anything that's truly
extensible, using custom headers is prone to future conflicts. To address
this issue, the HTTP Extension Framework has been proposed and submitted to
the
W3C as an Internet Draft (
http://www.w3.org/Protocols/HTTP/ietf-http-ext/).

The HTTP Extension Framework makes it possible to associate an extension
identifier, which is simply a URI, with the custom HTTP headers used for
application
specific purposes. The extension identifier acts as the extension namespace
and makes it possible to avoid future conflicts. The extension framework
also
provides a mechanism for making the extension declaration mandatory (using
the M- syntax). By simply prefixing the HTTP method with M-, such as M-POST,
the HTTP server is required to find and understand the identifier in the
extension declaration.
You'll notice that the SOAP request shown earlier uses a POST for the HTTP
method. While the SOAP specification allows both POST and M-POST requests,
it
states that clients are required to first attempt the request using M-POST.
If the client receives a response of "501 Not Implemented" or "510 Not
Extended,"
it should try the request again using a standard POST. The specification
also allows the client to continue using standard POST requests against that
same
server for the next 24 hours, at which point it's required to attempt
another M-POST request to account for server or firewall upgrades.
The following example illustrates how to convert the previous example into
an M-POST request:


M-POST /cgi-bin/purchase-book.cgi HTTP/1.1
Man: "http://www.microsoft.com/protocols/ext/SOAP"; ns=01
01-MethodName: PurchaseBook
01-InterfaceName: soap:cdl:com.develop.demos.purchase_book
01-MessageType: Call
Content-Type: text/xml-SOAP

<PurchaseBook>
<ISBN>0201379368</ISBN>
</PurchaseBook>

Again, the M-POST method specifies that an extension declaration is
mandatory for this HTTP request, and therefore a Man header must be present.
The Man
header contains the extension identifier along with a two-digit extension
prefix. The prefix is used on each custom HTTP header that belongs to the
extension,
as shown in this example. This mechanism is similar to the XML namespace
standard, which allows an arbitrary URI to scope a set of identifiers.
You may be wondering why additional HTTP headers for MessageType,
MethodName, and InterfaceName are used. Couldn't this information be
embedded in the SOAP
XML payload? The answer is yes-SOAP could have left off these headers and
contained the information in the XML payload. However, the reason for using
HTTP
headers has to do with firewall filtering.

Firewall Filtering
Firewalls can set filters for HTTP requests with a Content-Type:
text/xml-SOAP. They can also force clients to use only M-POST by prohibiting
regular POSTs
of Content-Type: text/xml-SOAP. Since firewalls can force the use of M-POST,
they can also be configured to allow only certain interfaces or methods to
pass through by looking at the InterfaceName and MethodName extension
headers defined by SOAP.
As outlined in the SOAP specification, the MethodName header is always
required. If an interface name is required to perform the operation, the
InterfaceName
header must also be present. The SOAP server is required to deny the request
if it doesn't understand these headers or a header doesn't match the
corresponding
information contained in the XML payload.
Without these SOAP headers, firewalls would have to scrape through the XML
payload to filter by method name, interface name, or even message type. This
would require firewalls to be more SOAP-aware.

SOAP XML Payload
The SOAP XML payload contains the encoded method-call information. In SOAP,
the XML payload serves the same purpose as the Network Data Representation
in
DCOM or the Common Data Representation in CORBA. For a SOAP request, the XML
payload consists of several elements including a root element, a method
element
(referred to as the call element), and optional header elements:


<SerializedStream>        <!-- root element -->
<headers>             <!-- headers element -->
<!-- header elements go here -->
</headers>
<PurchaseBook>        <!-- call (method) element -->
<!-- parameter elements go here -->
</PurchaseBook>
</SerializedStream>

The SOAP root element is the top element in the XML payload tree. It
provides the serialization context for the SOAP method call data stream.
Hence, the
SOAP specification gives it the name SerializedStream. If SerializedStream
is going to have only a single child element for a given method call
(meaning
it won't use any SOAP header elements), using the root SerializedStream
element is optional. For example, this XML payload


<SerializedStream>    <!-- root element -->
<PurchaseBook/>    <!-- call (method) element -->
</SerializedStream>

is equivalent to this one:


<PurchaseBook/>        <!-- root & call (method) element -->

The SerializedStream element must contain an attribute named main, whose
value is a standard URI fragment identifier that points to the call element
for
the given request. If a headers element exists, it must also contain another
URI fragment identifier named headers, which references the headers element:


<SerializedStream headers="#ref-0" main="#ref-1">
<headers id="ref-0">
<!-- header elements go here -->
</headers>
<PurchaseBook id="ref-1">
<!-- parameter elements go here -->
</PurchaseBook>
</SerializedStream>

These reference attributes make it possible for SOAP implementations to do
quick retrievals of the call or headers elements by ID. The SerializedStream
element may also contain a serializationPattern attribute, which identifies
the version of the SOAP specification that this message was coded against.
The call element contains all the information related directly to the method
invocation. The element name must be the same as the method name used in the
MethodName HTTP header. The element must contain an id attribute that
distinguishes it from other child elements of the root SerializedStream
element.
The call element also contains a child element for each [in] and [in/out]
parameter for the given method. These elements can use either the defined
parameter
name as the element name or a more generic approach that allows you to use _
_param0, _ _param1, ... _ _paramn, where n is the number of parameters minus
one. For example, this payload


<PurchaseBook>
<ISBN>0201379368</ISBN>
</PurchaseBook>

is equivalent to this one:


<PurchaseBook>
<_ _param0>0201379368</_ _param0>
</PurchaseBook>

The headers element may contain additional information not directly related
to the method invocation for the given request. The headers element must
contain
an id attribute that distinguishes it from other child elements of the root
SerializedStream element. The headers element also contains a list of header
entries. The SOAP specification lists some standard header entries you can
use including InterfaceName, MethodSignature, and UnorderedParams. You can
also
pass any other type of implicit information that needs to flow with the
request, but is not directly related to the method invocation, such as a
transaction
ID or session state information (think cookies).


<SerializedStream SerializationPattern="urn:schemas-microsoft-com:
soap:v1"
headers="#ref-0" main="#ref-1">
<headers id="ref-0">
<InterfaceName>
soap:cdl:com.develop.demos.purchase_book
</InterfaceName>
<CustomerID>
CDFE06E0-4DB4-4809-A7CF-4DDA32D5B081
</CustomerID>
</headers>
<PurchaseBook id="ref-1">
<_ _param0>0201379368</_ _param0>
</PurchaseBook>
</SerializedStream>

SOAP Response
A SOAP response should be identified by a value of CallResponse in the
MessageType HTTP header. A response contains a response element instead of
the call
element in the payload. The response element should be named the same as the
method name, with Response tacked on the end. For example, for the method
PurchaseBook, the response element would be named PurchaseBookResponse.
If the method returns a value, the response element may contain a _ _return
element containing the return value:


<SerializedStream
SerializationPattern="urn:schemas-microsoft-com:soap:v1"
headers="#ref-0"
main="#ref-1" >
<headers id="ref-0" >
<InterfaceName>
soap:cdl:com.develop.demos.purchase_book
</InterfaceName>
</headers>
<PurchaseBookResponse id="ref-1" >
<_ _return>Thank you!</_ _return>
</PurchaseBookResponse>
</SerializedStream>

It will also contain one child element for each [in/out] or [out] parameter.
Again, these element names can either be the same as the defined method
names
or you can use the _ _paramN approach.
If the method returns an error, the response element will contain a child
element named _ _fault. The fault element can contain detailed error
information
for the given request including a fault code, a fault string, and a special
run code that tells you if the request reached the destination:


<SerializedStream
SerializationPattern="urn:schemas-microsoft-com:soap:v1"
headers="#ref-0" main="#ref-1" >
<headers id="ref-0" >

<InterfaceName>
soap:cdl:com.develop.demos.purchase_book
</InterfaceName>
</headers>
<PurchaseBookResponse id="ref-1" >
<_ _fault>
<faultcode>400</faultcode>
<faultstring>Bad Request</faultstring>
<runcode>1</runcode>
</_ _fault>
</PurchaseBookResponse>
</SerializedStream>

SOAP Security
What about SOAP and security? Besides the firewall security benefits of
designing SOAP using extended HTTP headers, the SOAP specification does not
define
any protocol-specific security features. Because SOAP is layered on top of
HTTP, it may utilize any standard HTTP security feature or any endpoint
application-specific
security feature. SOAP requests are free to take advantage of HTTP
authentication mechanisms as well as SSL for secure channel communications
(using HTTPS).

A Generic SOAP Client
I've provided a generic SOAP client for Internet Explorer 5.0 to accompany
this article (see Figure 1). You can download this sample from the link at
the
top of this article or from my personal Web site at
http://www.skonnard.com/soap.
The sample will help you learn the SOAP protocol, and before you know it
you'll be making your first SOAP method calls.

Figure 1: Generic SOAP Client

Figure 1: Generic SOAP Client

This SOAP client allows you to easily build a SOAP request to any SOAP
endpoint. You type in the endpoint you want to call along with the method
and interface
names for the given method call. The sample builds a standard SOAP payload
and includes the appropriate SOAP HTTP headers in the request (including
Content-Type,
MessageType, MethodName, and InterfaceName). It also gives you a starting
point for the XML payload. As you type in the method and interface names, it
will add the call tag using the method name and a header tag using the
interface name. Then all you do is type in any parameter values inside of
the call
tag (where it says ENTER_ PARAMETERS).
The client also allows you to specify whether you will use POST or M-POST
for a given request. If you will use M-POST, it allows you to enter the
extension
identifier along with an associated prefix. The client will then include the
extension declaration in the HTTP request and prefix the SOAP HTTP headers
with the supplied extension prefix. Not all HTTP servers are configured to
support the M-POST method, so the client allows you to use POST.

Figure 2: SOAP Request

Figure 2: SOAP Request

After you've built the SOAP request, press the Call Method button to send
the request to the specified endpoint. After the call returns, the client
will
display all of the SOAP request and response information to help you become
more familiar with the protocol specifics (see Figure 2 and 3).

Figure 3: SOAP Response

Figure 3: SOAP Response

The sample also includes a handful of predefined SOAP endpoints that exist
on test SOAP servers at DevelopMentor (
http://www.develop.com/soap).
Some of the endpoints are COM components implemented in Visual Basic, while
others are Perl objects running on a Linux box. To use one of these
endpoints,
select it from the Test Endpoints combobox and the entire SOAP request will
automatically appear in the form. For more detailed descriptions of the
different
test SOAP endpoints, click on [show descriptions] (see Figure 4). When you
choose one of the Perl endpoints (reverse_string), you're calling a Perl
object
directly from a Windows script.

Figure 4: Test Endpoints

Figure 4: Test Endpoints

Although I've covered the basics of SOAP in this section, you'll want to
read the SOAP specification for more details. As you can see, SOAP itself is
very
simple. It only defines how to encode and transmit method invocations and
responses using HTTP and XML. To do something useful with SOAP, you'll have
to
write code to build and send the SOAP request from the client as well as
code to understand the SOAP response on the server. While you could surely
do
this by hand, it would make things much easier if there were some natural
language bindings for SOAP.

Language Bindings
To make SOAP work, there has to be code running on the client that is
responsible for building the SOAP request. There must also be code on the
server that
is responsible for understanding the SOAP request, invoking the specified
method, building the response message, and returning it to the client. The
SOAP
specification leaves these implementation details up to the developer.
In the case of my generic SOAP client for Internet Explorer 5.0, I've
provided the test endpoints that automatically generate the appropriate SOAP
request
and payload. If you want to call something other than one of the test
endpoints, you have to type in some of the SOAP HTTP/XML information by
hand. In
order for clients to start using SOAP quickly, you need transparent language
bindings that hide the SOAP details. After all, when you call a DCOM method,
you don't have to worry about building the DCOM packets; it all happens
transparently, behind the scenes. For SOAP to really take off, you need that
same
level of transparency for SOAP clients and servers.
Because the SOAP protocol has been kept simple, implementing these language
bindings shouldn't be a major development effort. Over the past few months,
DevelopMentor has been working on SOAP implementations for Perl, the Java
language, and COM. You can get information about these reference
implementations
from DevelopMentor's SOAP site at
http://www.develop.com/soap.

To illustrate SOAP's simplicity, it took one developer about one month to
write a robust and complete Perl implementation of SOAP. This implementation
allows
you to write standard Perl objects and expose them through SOAP. For
example, consider the following Perl object that contains the reverse_string
method
(this is one of the test endpoints available in the sample):


package Demo;
use strict;
sub new { bless \do{my $self}; }
sub reverse_string {
my ($self, $s) = @_;
return scalar(reverse $s);
}
1;

To expose this Perl object through SOAP, you could create the following
simple CGI script that uses the DevelopMentor Perl SOAP implementation:


#! /usr/bin/perl
use strict;
use SOAP::Dispatcher;

my $d = SOAP::Dispatcher->new();
my $classes = ['SoapOnLinux', 'Demo'];
$d->handle_cgi_post($classes);

This CGI script simply uses SOAP:: Dispatcher to process the SOAP request.
The $classes variable passed to handle_cgi_post lets you to specify the
class
names that are allowed to be called from the outside world- this adds an
additional layer of application security.
Remember, using SOAP you can call this Perl object from any client on any
platform using any language that supports HTTP and XML. The Perl language
binding
makes it especially easy to make SOAP method calls from Perl clients. For
example, the following Perl script calls the reverse_string method using
SOAP:


use strict;
use SOAP::Proxy;

my $proxy = SOAP::Proxy->new();
$proxy->set_itf_name('com.develop.demos.string_test');
$proxy->set_endpoint('http://localhost/testendpoint/nph-testcgi.pl?
class=Demo');
print $proxy->reverse_string('!dlrow olleH');

Notice how simple this script looks. There are no signs of HTTP, and no
signs of XML. It creates a new SOAP::Proxy, sets the endpoint and interface
name,
and starts calling methods through the proxy. Everything else happens
transparently. The proxy will take care of setting the appropriate HTTP
headers in
the request and encoding the reverse_string method call using XML. It will
also receive the HTTP response and process the XML payload for the result.
DevelopMentor has also developed a SOAP binding for standard COM clients and
servers. Any COM server can be exposed through either an ASP page or an
ISAPI
DLL. The following ASP allows you to call methods on the
VBSoapSrv.VBSoapTest component implemented in Visual Basic:


<%@ language=javascript %>

<object classid="clsid:2AD287C9-D8C2-4F53-A7B3-D297FDBF097A"
id=SoapCall runat=server></object>
<object progid="VBSoapSrv.VBSoapTest" id=TargetObject
runat=server></object>
<script language=javascript runat=server>

if (SoapCall.Init("soap", false))
{
SoapCall.Invoke(TargetObject);
SoapCall.WriteResponse();
}

</script>

This creates an instance of the VBSoapSrv.VBSoapTest component through an
<OBJECT runat=server> tag and delegates the work to the SoapCall component
(which
acts like a COM stub) to take care of the rest. The SoapCall component
performs the same role as the SOAP::Dispatcher in the Perl implementation.
On the client side, DevelopMentor provides a transparent proxy that hides
all the SOAP details. And to make things even easier, they offer a SOAP
moniker
to bind your code to the proxy. Check out the following example, which uses
the SOAP moniker:


Dim itf As VBSoapSrv.VBSoapTest

Private Sub Command1_Click()
set itf = GetObject("dm.soap:http://soap.develop.com/soap/page.asp")
strOrigin = itf.GetOrigin()
MsgBox strOrigin
End Sub

SOAP can't get much more transparent than that. The proxy builds, sends, and
receives the underlying SOAP request for each method call (like GetOrigin).
Besides the Perl and COM implementations, there is also a Java language
binding. As of the writing of this article, both the COM and Java bits were
still
under development. Point your browser to
http://www.develop.com/soap
for more details on the current state of these implementations.
At this point, I want to emphasize that these language bindings are not part
of SOAP itself. They only make SOAP easier to use from their respective
environments.
Other organizations are free to produce their own SOAP implementations that
improve upon these and make SOAP a more integral part of their products and
services.

Additional SOAP Resources
Userland Software, Microsoft, and DevelopMentor drafted the original SOAP
specification back in 1998. The current SOAP specification has been
submitted
to the Internet Engineering Task Force and can be read online at
http://msdn.microsoft.com/ workshop/xml/general/SOAP_V09.asp. Public
statements about
plans to support the SOAP protocol have been made by several companies:
List of 5 items
. DevelopMentor provides implementations of SOAP for Perl, the Java
language, and COM (
http://www.develop.com/soap)

. Rogue Wave's Nouveau ORB is planning to have support for SOAP in place
soon (http://www.roguewave.com/ company/pressrel/pr20sep99.html)
. The Frontier groupware product plans to support SOAP (
http://frontier.userland.com/toc)

. The IONA iPortal Suite has also announced support for SOAP
(http://www.iona-iportal.com/news/prsuite.htm)
. Microsoft plans to support SOAP as a mechanism for bridging object models
list end
For more information on the development of the SOAP protocol and the
different ongoing SOAP implementations, be sure to visit DevelopMentor's
SOAP site,
where you can read the SOAP FAQ and join the SOAP mailing list.

Conclusion
Although SOAP can be made easier to use through natural language bindings,
SOAP does not mandate an API of any kind; a language binding is strictly an
implementation
that makes SOAP more accessible and easy to use. SOAP also doesn't attempt
to address the more complicated distributed object protocol services such as
object activation, marshaling objects/references, garbage collection, or
bidirectional communications. SOAP doesn't prevent you from using any of
these
services; they are simply implementation details that can be layered on top
of the SOAP protocol.
SOAP is simple. It is nothing more and nothing less than a protocol that
defines how to access services, objects, and servers in a
platform-independent
manner using HTTP and XML. As the industry embraces this technology, it will
open up a new world of interoperability that promotes further progress
toward
developers working together.

From the
January 2000
issue of
Microsoft Internet Developer.

Get it at your local newsstand, or better yet,
subscribe.
Contact Us
 |
E-Mail this Page
 |
MSDN Flash Newsletter
 |
Legal

 © 2003 Microsoft Corporation. All rights reserved.
Terms of Use
Privacy Statement
Accessibility

Re: [Amis-devl] Links for object communication

[Dinesh K. <din...@ho...>]

Hi all,

UNO (Universal Network Objects) is also one possible approach. it is part of
open office and is available for various platforms.

-----------

UDK Project

UNO (Universal Network Objects) is the interface-based component model of
OpenOffice.org. UNO offers interoperability between different programming
languages,
different object models, different machine architectures and different
processes; either in a local network or even via the internet. UNO
components can
be implemented in and accessed from any programming language for which a UNO
language binding exists.

Currently there are complete UNO language bindings for:
List of 4 items
. C
. C++ (compiler dependent, please see
http://porting.openoffice.org
for a list of supported platforms)
. Java
. Python
list end

Additionally, there are bindings that allow to access UNO components, but do
not support the development of new UNO components:
List of 3 items
. OpenOffice.org Basic
. Object Linking and Embedding (OLE) Automation
. Common Language Infrastructure (CLI). Note: The Microsoft .NET framework
is an implementation of this standard. The
language binding
does NOT have the status "final" yet. Therefore do NOT use it (and programs
based on it) in a production environment.
list end

OpenOffice.org Software Development Kit

There is a
Software Development Kit
available which is an add-on for OpenOffice.org. It provides tools, examples
and documentation needed to write applications that use existing UNO
components
as well as to develop new UNO components.

Documentation

Concepts

Table with 2 columns and 8 rows

Professional UNO
Chapter from the
OpenOffice.org SDK's Developer's Guide.
It explains the basic concepts of UNO, contains a complete introduction to
language independent UNO and API concepts (including remote UNO
communication),
gives detailed information on the Java, C++, OpenOffice.org Basic and OLE
Automation UNO binding.

Writing UNO Components
Chapter from the
OpenOffice.org SDK's Developer's Guide.
It explains how to write UNO components.

Advanced UNO
Chapter from the
OpenOffice.org SDK's Developer's Guide.
It covers advanced topics, for example how to implement a UNO language
binding.

UNO Bridge Concept
How to translate the calls from one language into another one.

UNO Contexts
UNO Component and Current Context

UNO Security
UNO Security Model

Streaming Services
Introduction into the UNO streaming concepts

UNO CORBA Bridge
Concepts for a UNO CORBA bridge (not yet implemented).
table end

Specifications

Table with 2 columns and 21 rows

C++ Bridges
This document is written for developers implementing a bridge from C++ to
binary UNO. The last paragraph covers the Microsoft Visual C++ - UNO bridge
in
detail.

Binary Type Library
Binary specification of the UNO type library.

UNOIDL
(Developer's Guide)
Syntax Specification

Binary UNO Specifaction
Specification of binary (C-)UNO types. This is the platform-dependent
intermediate (bridging) format.

C++ Language Binding
(Developer's Guide)


Java Language Binding
(Developer's Guide)


Mapping between UNO and Java Types
Information on how the UNO type system maps to the Java language binding

Java Language Binding


OpenOffice.org Basic Language Binding
(Developer's Guide)


OLE Automation Binding
(Developer's Guide)


C Language Binding
Specification of C UNO types.

UNO Remote Protocol (URP)
Binary specification of the (a UNO interprocess protocol).

Library Unloading
API that offers a way to unload all unused libraries at once

Default Bootstrapping
Specification for Bootstrap Arguments and UNO Default Bootstrapping

Micro Deployment
Specification for Bootstrap Arguments and Micro Deployment

Text Conversions
Specification of the text conversion functions in SAL

URIs in UDK
Specification of how URIs are used within UDK/OOo

Naming UNO Components
Rules for how UNO components should be named

UNO Object Life Cycle Model
A specification and explanations of object life cycle concepts

UNO Execution Model
A foundation for a UNO execution semantics

UNO Type System
A specification of the UNO type system
table end

Drafts

Table with 2 columns and 9 rows

COM
COM -  UNO language specification

UNO and SOAP
Considerations

UNO Synchronization and Multi Threading
Reflect the current state of handling multi threading and synchronization in
UNO

Remote Visualization and Oneways
Example of non transparent remote visualization

Logging
Concepts and specification of a Logging API/framework

Stack Traces for UNO Exceptions
A concept for automatically generated stack traces for UNO exceptions

Names in UNO
How names are used in core UNO, and how these names map to UNO IDL and
language bindings

Mapping between UNO and CLI Types
Mapping between UNO types and CLI types (.NET) from the Common Language
Specification

CLI-UNO Language Binding
A Language Binding for CLI languages, such as C# and VB.NET
table end

Tutorials/Examples

Table with 2 columns and 3 rows

Guide to C++ UNO
This document gives an introduction to the C++ mapping of UNO.

Registries in UNO
Explains the UNO registry handling and how components can be added to
OpenOffice.

UNO Web service proxy
A UNO component which allows one to access Web services by UNO and
StarBasic.
table end

References

Table with 2 columns and 3 rows

OpenOffice.org IDL Reference
Reference containing all UDK and OpenOffice.org UNO types

UDK C/C++ API Reference


UDK Java API Reference

table end

Tools and FAQ

Table with 2 columns and 2 rows

Tools
Description of all command line tools

FAQ
Frequently asked questions about UNO
table end

Links

Table with 2 columns and 3 rows

PyUNO
Python-UNO bridge, maintained by Joerg Budischewski

PerlUNO
Perl-UNO bridge project (external), maintained by Bustamam Harun

OpenOffice.org Scripting Framework

table end

Tasks

Table with 2 columns and 2 rows

Open tasks
Some ideas how YOU can contribute to the project.

API tests
Help implement API tests.
table end

Table with 2 columns and 16 rows

Modules in UNO Development Kit Project

Module
Function

cppu
The UNO runtime library which is used by all language bindings except Java.

idlc
The UNOIDL compiler.

cppuhelper
C++ UNO implementation helpers.

javaunohelper
Java UNO Helper implementations.

jurt
Java UNO runtime. Contains the runtime of the Java language binding for UNO.

bridges
The bridges to different languages like C++ (MS Visual C++, SUNWspro5 SPARC,
GCC3, ...), Java and remote.

remotebridges
Contains UNO services related to interprocess UNO bridges.

stoc
Basic UNO services.

cpputools
Collection of UNO utility and runtime programs.

registry
The implementation of the registry.

codemaker
Contains the programs to generate c++ header files, Java files and CORBA IDL
files. The programs work on a binary type repository which is generated by
the unoidl compiler.

rdbmaker
Generate binary type repository subset from the binary type repository or
with the service com.sun.star.reflect.TypeDescriptionManager.

sandbox
A Java security manager based on Java 1.1.

jut
Java UNO Tools - a collection of Java utilities. Serves the same purpose as
cppuhelper does for C++ UNO.
table end

Table with 2 columns and 4 rows

Interesting modules outside the UNO Development Kit Project

Module
Function

sal
The System abstraction layer implements a basic abstraction of the
underlying system. For your components to be system independent you should
use SAL. SAL
includes abstractions for thread creation and synchronization. Mechanisms
for process communication and file system access are also part of this
library.
Management of libraries and profiles is also included. Functions for
creating and manipulating strings and wide strings belong to SAL. The
functionality
of SAL is splitted in two namespaces
osl (system functions)
and
rtl (strings and memory management).
SAL only exports functions conforming to the C calling convention. So, it
should be suitable to be a system abstraction for any language.

store
This project provides the hierarchical storages for the component registry.
table end

We welcome your
feedback.

CollabNet, Inc. CollabNet is a trademark of CollabNet, Inc.
Sun, Sun Microsystems, the Sun Logo, Solaris, Java, StarOffice, StarOffice
7.0 and StarSuite 7.0 are trademarks or registered trademarks of Sun
Microsystems,
Inc., in the United States and other countries.

images/collabnetlabel

This site sponsored by
Sun Microsystems, Inc.

----- Original Message -----
From: "Pranav Lal" <no...@vs...>
To: <ami...@li...>
Sent: Sunday, October 26, 2003 11:43 AM
Subject: [Amis-devl] Links for object communication


> Hi all,
>
> I have been doing some searching on technologies that will let AmisNext's
> objects talk to one and other cross platform. Manish had mentioned that
one
> such technology is soap.
>
> A reasonably good article on soap is at the following link
> http://www-106.ibm.com/developerworks/library/ws-peer2/
>
> It follows a hands on approach to the topic. I have not had the time to
> read the complete article but will do so in some time. The examples
require
> the reader to download tomcat and I suspect the soap sdk which could be a
> challenge on a dialup connection.
>
> By the way, to those of you who don't know what I am talking about, there
> was a daisy for all workshop conducted in Thailand from the 19th to the
> 24th of October 2003. The discussion of amisNext specifications was
brought
> up at this workshop. Marisa will have more on this once she gets her paper
> notes into electronic format.
>
> Pranav
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Amis-devl mailing list
> Ami...@li...
> https://lists.sourceforge.net/lists/listinfo/amis-devl
>

[Amis-devl] Links for object communication

[Pranav L. <no...@vs...>]

Hi all,

I have been doing some searching on technologies that will let AmisNext's 
objects talk to one and other cross platform. Manish had mentioned that one 
such technology is soap.

A reasonably good article on soap is at the following link
http://www-106.ibm.com/developerworks/library/ws-peer2/

It follows a hands on approach to the topic. I have not had the time to 
read the complete article but will do so in some time. The examples require 
the reader to download tomcat and I suspect the soap sdk which could be a 
challenge on a dialup connection.

By the way, to those of you who don't know what I am talking about, there 
was a daisy for all workshop conducted in Thailand from the 19th to the 
24th of October 2003. The discussion of amisNext specifications was brought 
up at this workshop. Marisa will have more on this once she gets her paper 
notes into electronic format.

Pranav 

[Amis-devl] Re: [Dsidtb-amisdev] java or .net

[Marisa D. <mar...@ya...>]

Hi,

For Amis-Next, the plan is that we'll write
cross-platform core libraries in c/c++, and attach
interfaces (GUIs, plug-ins, etc) to them.  Hopefully
we can support several different languages for these
interfaces.

One great big important decision is how to wrap these
core libraries - COM or something - to make
communication between objects easier.

you can read more about this at amis.sourceforge.net. 
I'm still working on the architecture but the outline
is there.  

discussion for amis-next is on the
"ami...@li..." list.

Regarding Java and .Net, I hope we can find a way to
wrap the core objects so that interfaces written in
Java and .Net can be implemented easily.  

marisa

--- Dinesh Kaushal <din...@ho...> wrote:
> Hi all,
> I was just contemplating about the implementation
> platform for the next
> version of AMIS, and thought if we could port to
> .net as well?
> 
> .net will also be cross platform and is available as
> compact framework as
> well. there is some work going on for linux, as in
> mono project or dotGNU
> project and some others.
> 
> regards
> 
> another issue is that porting current version might
> just be an automatic
> upgrade from vb6 to vb.net with minor currections
> which are anyways
> indicated by the upgrade process itself.
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dsidtb-amisdev mailing list
> Dsi...@li...
>
https://lists.sourceforge.net/lists/listinfo/dsidtb-amisdev
> 
> 
> 

[Amis-devl] Re: Ang: [Dsidtb-amisdev] SMIL Engine documents

[Marisa D. <ma...@di...>]

 This might be specific to my logic and pseudo-code, but I found it 
helpful to know each object's duration when you have to calculate 
offsets that might cross some lines.... This is not the same thing 
exactly that you are talking about, I don't think it is as advanced.  
But it was an issue I found, when looking at the sort of Smil that could 
be allowed for Daisybooks.  For example:

1. seq
    1.1 seq
       1.2 par
          1.2.1 audio (0-7s)
          1.2.2  text
       1.3 par
          1.3.1 audio (7-10s)
          1.3.2 text
    1.2 par
       1.2.1 audio (10-20s)
       1.2.2. text

* audio clips given with (start-end) time.

This might be Smil code that we would never encounter.  But let's take 
it as an example.  Let's say our entry point into this document is SEQ 
(#1) + 15s.

If our marker had no offset, we would just start playing the child 
nodes, left-to-right.  But with an offset, it becomes useful to know the 
duration of each subtree, because then we can choose our path intelligently.

So if the tree had duration values, it would look like this:
1. seq 20s
    1.1 seq 10s
       1.2 par 7s
          1.2.1 audio (0-7s) 7s
          1.2.2  text 7s
       1.3 par 3s
          1.3.1 audio (7-10s) 3s
          1.3.2 text 3s
    1.2 par 10s
       1.2.1 audio (10-20s) 10s
       1.2.2. text 10s

Our marker at Seq (#1)+ 15s is processed like this:

    1.  Is Seq (#1) + 15s valid? Yes, because Seq (#1) has a total 
duration of 20s.
    2.  Look at each child node, left to right
    3.  keep a local count of durations and lower the offset as we 
bypass nodes
        3.1 eg, after seeing that Seq (#1.1) + 15s cannot be done, add 
10s to the duration count and subtract 10s from the offset
         3.1 so now we are looking at the next possibility, which is Par 
(#1.2) + 5s
    4.  find the best fit at each level

This would not have us even attempting to look at the nodes under Seq 
(#1.1) because they would be immediately ruled out.

Two things this does not cover:

1.  What Markus brought up -

 <audio clip-begin="0s"/>

2. If the marker were at Seq + 23s, meaning that some other place in the 
book, not existing under that Seq subtree, was the desired location.

For the first case, I'll be sure to put code in that says, when 
searching for an offset, if you find an audio node with no specified 
duration, try to use it as the target media object (plus whatever the 
requested offset was). If the offset exceeds the audio file length, we 
can either
    a. have the interface call the smil engine and ask it to try again
    b. say this is a lousy bookmark, too bad

For the second case, I would say that is a pretty dumb marker, to be 
somewhere buried in the smil-tree and then have your offset not exist in 
that subtree.

What do you all think ?

later,
marisa

Markus Gylling wrote:

>So this is a local internal clock for each time container? Are there interrelations (communication needs) between nested clocks?
>What happens when a media object (an audio file for example) is still being rendered when it according to the clock should have terminated. Who wins? What happens when there is no duration information at all in the time container, thus:
><par>
> <text .../>
> <audio clip-begin="0s"/>
></par>
>The only way to get a clock now is to go out to the audio renderer and ask it to return the length of the file, right?
>Or can (this is where I am getting) certain clocks remain unknown, be defeated when proven inaccurate, and the system still works.
>
>
>  
>
>>>>Karl Ekdahl 2003-09-09 11:57 >>>
>>>>        
>>>>
>Disregarding the fact that huge parts of the SMIL 1.0 and SMIL 2.0 specifications are 
>dedicated to these calculations and that NOT calculating them would be (at least as i see it)
>a specificational error, it gives you several advantages;
>
>* the ability to easily, using pure logic, be able to calculate when objects should be
>  rendered without the need of 'specialized' functions.
>* the ability to ignore objects that shouldn't be renderd.
>* the ability to rendered objects after a certain amount of time (e.g. showing an image
>  when an audio has played 3 seconds).
>* the ability to easily do a logically working positioning within a smil using ID and time (not fully   thought trough yet)
>* being able to actually calculate when a par that doesn't have endsync 'last' actually
>  ends.
>
>etc.
>Most of the items above are saying the same thing; I'm NOT suggesting a real-time masterclock, but a way of measuring when objects should be presented using a logical calculation that could be re-used in all objects. I'm currently doing some minor investigation on the subject of positioning, bookmarking, 'clocking' etc.
>
>/Karl
>
>  
>
>>>>mar...@tp... 2003-09-09 11:40:05 >>>
>>>>        
>>>>
>I still need to understand why object master timing calculation is needed. My starting point for saying this is that we have a overarching situation where the media object timing always wins (this implicit duration is explicitly stated in the time containers).
>So - Karl - please enlighten me. Is it for future use? Is it needed in our current (2.02 and 3) smil implementations as well?
>/markus
>
>  
>

[Amis-devl] SMIL Engine documents

[Marisa D. <ma...@di...>]

Hi all,

Amis architecture and smil engine docs can be found here:

http://amis.sourceforge.net/arch/amis.arch.html

I'll be continuously updating these documents, they're not finished, but 
I think we can start/continue discussions.

BTW there is a new list for amis-next development, the address is 
ami...@li....  You can sign up at: 
http://lists.sourceforge.net/lists/listinfo/amis-devl

-marisa

[Amis-devl] test post

[Marisa D. <ma...@di...>]

please ignore