[PATCH 1/7] wsdapi: Add wsdapi_internal.h for shared internal function and macro definitions.

[Owen Rudge]

This patch series adds the initial implementation of the PublishEx 
function for the IWSDiscoveryPublisher interface. The basic structure of 
the SOAP message is built up, written as XML to a string buffer, then 
sent via UDP multicast.

The full population of the message will follow in a further patch series.

Signed-off-by: Owen Rudge <orudge(a)codeweavers.com>
---
  dlls/wsdapi/address.c         |  6 +-----
  dlls/wsdapi/wsdapi_internal.h | 35 +++++++++++++++++++++++++++++++++++
  dlls/wsdapi/xml.c             |  7 +------
  3 files changed, 37 insertions(+), 11 deletions(-)
  create mode 100644 dlls/wsdapi/wsdapi_internal.h

[Huw Davies]

On Wed, Mar 07, 2018 at 10:51:39PM +0000, Owen Rudge wrote:
> This patch series adds the initial implementation of the PublishEx 
> function for the IWSDiscoveryPublisher interface. The basic structure of 
> the SOAP message is built up, written as XML to a string buffer, then 
> sent via UDP multicast.
>
> The full population of the message will follow in a further patch series.

Hi Owen,

Is it possible to query the soap message in some way as it's built up?

Huw.
> Signed-off-by: Owen Rudge <orudge(a)codeweavers.com>
> ---
>   dlls/wsdapi/address.c         |  6 +-----
>   dlls/wsdapi/wsdapi_internal.h | 35 +++++++++++++++++++++++++++++++++++
>   dlls/wsdapi/xml.c             |  7 +------
>   3 files changed, 37 insertions(+), 11 deletions(-)
>   create mode 100644 dlls/wsdapi/wsdapi_internal.h
>
> diff --git a/dlls/wsdapi/address.c b/dlls/wsdapi/address.c
> index 8e9d475118..d6be6a2c57 100644
> --- a/dlls/wsdapi/address.c
> +++ b/dlls/wsdapi/address.c
> @@ -22,12 +22,8 @@
>
> #define COBJMACROS
>
> -#include "winsock2.h"
> -#include "ws2tcpip.h"
> -#include "windef.h"
> -#include "winbase.h"
> +#include "wsdapi_internal.h"
>  #include "wine/debug.h"
> -#include "wsdapi.h"
>
> WINE_DEFAULT_DEBUG_CHANNEL(wsdapi);
>
> diff --git a/dlls/wsdapi/wsdapi_internal.h b/dlls/wsdapi/wsdapi_internal.h
> new file mode 100644
> index 0000000000..22de4a842a
> --- /dev/null
> +++ b/dlls/wsdapi/wsdapi_internal.h
> @@ -0,0 +1,35 @@
> +/*
> + * Web Services on Devices
> + * Internal header
> + *
> + * Copyright 2017-2018 Owen Rudge for CodeWeavers
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
> + */
> +
> +#ifndef _WINE_WSDAPI_INTERNAL_H
> +#define _WINE_WSDAPI_INTERNAL_H
> +
> +#include "winsock2.h"
> +#include "ws2tcpip.h"
> +#include "windef.h"
> +#include "winbase.h"
> +#include "objbase.h"
> +#include "wsdapi.h"
> +#include "wine/list.h"
> +
> +#define WSD_MAX_TEXT_LENGTH    8192
> +
> +#endif
> diff --git a/dlls/wsdapi/xml.c b/dlls/wsdapi/xml.c
> index 824b7ff2fd..4d6319c36b 100644
> --- a/dlls/wsdapi/xml.c
> +++ b/dlls/wsdapi/xml.c
> @@ -22,16 +22,11 @@
>
> #define COBJMACROS
>
> -#include "windef.h"
> -#include "winbase.h"
> +#include "wsdapi_internal.h"
>  #include "wine/debug.h"
> -#include "wine/list.h"
> -#include "wsdapi.h"
>
> WINE_DEFAULT_DEBUG_CHANNEL(wsdapi);
>
> -#define WSD_MAX_TEXT_LENGTH 8192
> -
>  static LPWSTR duplicate_string(void *parentMemoryBlock, LPCWSTR value)
>  {
>      int valueLen;

[Owen Rudge]

On 12/03/2018 10:18, Huw Davies wrote:
> Is it possible to query the soap message in some way as it's built up?

Hi Huw,

I expect I could try to submit the patchset in reverse order - i.e., add 
code to send a (more or less empty) UDP message; then build up the SOAP 
message progressively (which is what I attempted to do with this 
series), sending what's generated at each stage. I don't know if that 
might be more acceptable?

The current unit tests I have for the Publish method look for particular 
IDs that are sent as part of the message. I may be able to add to these 
tests to see if it can pick out elements in a partial message, but at 
the moment it's looking for the completed message, as it's quite 
possible that the system being unit tested is receiving genuine messages 
from elsewhere on the network, which would then potentially cause false 
positives. The end result we want is a complete message, so adding these 
'intermediate' tests may not be very practical.

Thanks,

Owen

[Huw Davies]

On Mon, Mar 12, 2018 at 12:05:16PM +0000, Owen Rudge wrote:
> On 12/03/2018 10:18, Huw Davies wrote:
> > Is it possible to query the soap message in some way as it's built up?
>
> Hi Huw,
>
> I expect I could try to submit the patchset in reverse order - i.e., add
> code to send a (more or less empty) UDP message; then build up the SOAP
> message progressively (which is what I attempted to do with this series),
> sending what's generated at each stage. I don't know if that might be more
> acceptable?
>
> The current unit tests I have for the Publish method look for particular IDs
> that are sent as part of the message. I may be able to add to these tests to
> see if it can pick out elements in a partial message, but at the moment it's
> looking for the completed message, as it's quite possible that the system
> being unit tested is receiving genuine messages from elsewhere on the
> network, which would then potentially cause false positives. The end result
> we want is a complete message, so adding these 'intermediate' tests may not
> be very practical.

Hi Owen,

I was wondering whether the message could be read using some API, but
I expect that's not possible.  Failing that, then yes, sending an
empty message first and then adding code to progressively fill out the
message would be better.  If it's possible to easily add tests as you
go that would be nice, but having tests at the end of the series should
be enough.

Thanks,
Huw.