Xml messaging in erlang question

Joe Armstrong (TN/EAB) <>
Thu Aug 24 10:08:11 CEST 2006


My take on this:

	On input convert to VXML ... a 1:1 representation of the SOAP /
whatever formats

      Either use a generic parser - or a specialised parser (preferred)
if the format is
static and well known.

      Internally work with VXML (the Erlang representation) never,
never, never ever
store XML in a data base, only VXML if mnesia, or term_to_binary(VXML)
if something else.

      You haven't really said what small and big messages are.

       Large messages means to me "cannot hold them in RAM" if your
messages
are 10's or even hundred of KBs you still be able to hold thousands of
them in a couple of GBytes
of memory.

      Do not do any size optimisations yet (you might have to do them
later - but get the
code right *first* then *measure*) - if you think you might have to
optimise for size then plan
your data structures accordingly.

      On output convert VXML back to XML (if required)

      The golden rule

	Keep to VXML as much as possible.

	At a guess 90% + of your application CPU time will be spent
converting XML to VXML so
try to do this ONCE


 

/Joe
 

> -----Original Message-----
> From:  
> [mailto:] On Behalf Of bryan 
> rasmussen
> Sent: den 24 augusti 2006 09:49
> To: 
> Subject: Xml messaging in erlang question
> 
> hi List,
> 
> 
> The following question will basically be academic, I want to 
> get an idea of how people would use Erlang with the following 
> scenario, the actual application will not be using Erlang 
> (decisions made long ago by others)
> 
> Basically one has messages sent via SOAP over HTTP, these 
> messages can hold two variations of the same format, one the 
> international version the other localized.
> 
> The localized version disallows some structures found in the 
> international version making for a potentially smaller 
> message, basically the localized version would be best 
> processed using something that reads the whole XML structure 
> into memory and allows one to work with XPath etc. to get out 
> pertinent data.
> 
> The international version is potentially quite big and should 
> thus be streamed.
> 
> I'm considering streaming and then cutting out the parts that 
> are not important.
> 
> To determine whether an instance should be streamed we will 
> look at the size of the instance before choosing processing method.
> 
> I expect more of localized version, and would at any rate 
> want to privilege localized version in processing, allowing 
> localized messages to go quicker through the system.
> 
> Obviously each type of message needs to have various things 
> done to it, validation of messages, branching due to 
> validation problems, information from messages added to 
> database if valid, transformations of messages for display if 
> needed and so forth. Something like an XML Pipeline.
> 
> At a high architectural level what ways would people want to 
> use Erlang to solve this?
> 



More information about the erlang-questions mailing list