Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Dltk-dev] dbgp encoded property values

  i'm still in the process of getting some further details on this. i spoke w/ the active state people and it appears that the dbgp protocol has been changed, but the spec has not been updated to reflect the changes.

  basically, it seems that the "name" and "fullname" values which are currently expressed as attributes may also be expressed as a children elements of the property tag, instead of as attributes, ie:

    <value encoding="base64"><!CDATA[[xxxxx]]></value>

   it seems that it is possible for values of name/fullname to contain characters that can not be represented as attribute data. the tcl and ruby engines seem to follow the spec as is (the CDATA block directly under the property element), while the perl engine sticks the the cdata block in a 'value' element nested under the 'property' element. supposedly the python debugger goes a step further and uses name/fullname as elements instead of attributes, but i don't have any debugging session output to confirm that, just what the active state folks told me.

  in any case, i'm going to work on a patch for this that will first check to see if any of those 'keys' exist as a child element of the property tag, otherwise fall back to the current behavior of looking for name/fullname as attributes and the value as a direct child element of property.
On 7/10/07, Andrey Platov <andrey@xxxxxxxxx> wrote:

I believe the "problem" already described very well. Jae, please submit a
patch or just file a bug if you'd like Dmitriy to add such support for
ActiveState's debuggers.

Kind Regards,

-----Original Message-----
From: dltk-dev-bounces@xxxxxxxxxxx [mailto: dltk-dev-bounces@xxxxxxxxxxx] On
Behalf Of Dmitriy Kovalev
Sent: Tuesday, July 10, 2007 10:49 AM
To: DLTK Developer Discussions
Subject: Re: [Dltk-dev] dbgp encoded property values

DBGP spec on doesn't specify
<value>...</value> tag for properties. That's why DbgpXmlParser doesn't
support it. It's possible to modify DbgpXmlParser if using of
<value>...</value> tag is a common situation for ActiveState debugging
engines. I think you should submit a bug with detailed description of
this problem.
Dmitriy Kovalev

Jae Gangemi wrote:
>   does anyone know if the dbgp spec defined what the property element
> is supposed to look like when it contains the encoded  value data? the
> spec  gives this:
> <property
>     name="short_name"
>     fullname="long_name"
>     type="data_type"
>     classname="name_of_object_class"
>     constant="0|1"
>     children="0|1"
>     size="{NUM}"
>     page="{NUM}"
>     pagesize="{NUM}"
>     address="{NUM}"
>     key="language_dependent_key"
>     encoding="base64|none"
>     numchildren="{NUM}">
> ...encoded Value Data...
> </property>
>   but it seems to leave open exactly how the encoded value data is
> stored within the property element.
>   it seems that the active state's perl debugging engine returns a
> property element that looks like this:
>   <property fullname="$num" name="$num" encoding="base64"
> type="scalar" constant="0" children="0" size="5" >
>     <value encoding="base64">
>       <![CDATA[NQ==]]>
>     </value>
>   </property>
>   while the tcl implementation returns this:
>   <property name="$a" fullname="$a" type="string" size="1"
> children="0" encoding="base64">
>     <![CDATA[Mw==]]>
>   </property>
>   the parseContent method in DbgpXmlParser does not look to see if the
> property element has any grand children that may contain the value
> instead.
> --
> -jae
> ------------------------------------------------------------------------
> _______________________________________________
> dltk-dev mailing list
> dltk-dev@xxxxxxxxxxx

dltk-dev mailing list

dltk-dev mailing list


Back to the top