openslp-devel — development futures

Re: [Openslp-devel] [PATCH] simplify interface list parsing

[John C. <joh...@gm...>]

Broken windows build fixed - I had to add implementation for getifaddrs,
freeifaddrs, and strtok_r. 

Builds cleanly on vs2010 win32/x64 now.

--john

> -----Original Message-----
> From: John Calcote [mailto:joh...@gm...]
> Sent: Wednesday, November 28, 2012 12:50 PM
> To: 'David Stevens'
> Cc: ope...@li...
> Subject: RE: [Openslp-devel] [PATCH] simplify interface list parsing
> 
> Yeah - I was going to build on windows and see what broke shortly here.
> :)
> John
> 
> > -----Original Message-----
> > From: David Stevens [mailto:dls...@us...]
> > Sent: Wednesday, November 28, 2012 11:36 AM
> > To: John Calcote
> > Cc: ope...@li...
> > Subject: RE: [Openslp-devel] [PATCH] simplify interface list parsing
> >
> > John,
> >         Thanks. Nick Wagner in private e-mail pointed out that Windows
> MSVC
> > may not have the POSIX strtok_r() but instead uses strtok_s(). I don't
> have
> > MSVC to test or work around this so the second patch ("simplify
interface
> list
> > parsing") may need to wait for someone who does, or just leave the
> original
> > code.
> >         The other two patches are independent of this one, so it can be
> safely
> > left out if needed.
> >
> >                                                 +-DLS
> 

Re: [Openslp-devel] [PATCH] simplify interface list parsing

[John C. <joh...@gm...>]

Yeah - I was going to build on windows and see what broke shortly here.
:)
John

> -----Original Message-----
> From: David Stevens [mailto:dls...@us...]
> Sent: Wednesday, November 28, 2012 11:36 AM
> To: John Calcote
> Cc: ope...@li...
> Subject: RE: [Openslp-devel] [PATCH] simplify interface list parsing
> 
> John,
>         Thanks. Nick Wagner in private e-mail pointed out that Windows
MSVC
> may not have the POSIX strtok_r() but instead uses strtok_s(). I don't
have
> MSVC to test or work around this so the second patch ("simplify interface
list
> parsing") may need to wait for someone who does, or just leave the
original
> code.
>         The other two patches are independent of this one, so it can be
safely
> left out if needed.
> 
>                                                 +-DLS

Re: [Openslp-devel] [PATCHv2] semi-automatically refresh listening interfaces

[John C. <joh...@gm...>]

Hi Gavin,

Your dynamic ifc reinit patch has been incorporated into the repository.
Thanks for your efforts.

Regards,
John

> -----Original Message-----
> From: Gavin Lambert [mailto:ga...@co...]
> Sent: Thursday, October 25, 2012 9:32 PM
> To: ope...@li...
> Subject: [Openslp-devel] [PATCHv2] semi-automatically refresh listening
> interfaces
> 
> I've attached a variation of the previous patch (still against the 2.0
beta
> 2 tarball) which handles the reinit slightly differently from the
original.
> 
> This one will start listening on any newly discovered (or configured)
> interfaces, without closing or stopping any previously opened incoming
> sockets.
> 
> The advantage over the previous patch is that it will cause less
disruption to
> ongoing communications, particularly if only a secondary interface is
> changing.  The disadvantage is that if the service is left running for a
long time
> on a network that keeps assigning it different addresses (presumably via a
> DHCP server with a bad memory) then it will gradually eat up more and more
> resources, and probably eventually fail.  (I'm not sure which tradeoff is
better
> overall.)
> 
> A suggested improvement (which again I'm not quite familiar enough with
> the code to do at this point) would be to track which sockets are
associated
> with a particular interface and close them if their interface is not still
present
> during the reinit.
> 
> Note that for code simplicity it's currently assuming that if the TCP
listen
> socket exists then all the other related sockets are still ok too.

Re: [Openslp-devel] [PATCH] simplify interface list parsing

[David S. <dls...@us...>]

John,
        Thanks. Nick Wagner in private e-mail pointed out that Windows 
MSVC may not
have the POSIX strtok_r() but instead uses strtok_s(). I don't have MSVC 
to test or work around
this so the second patch ("simplify interface list parsing") may need to 
wait for someone
who does, or just leave the original code.
        The other two patches are independent of this one, so it can be 
safely left out
if needed.

                                                +-DLS

[Openslp-devel] .hgignore file added

[John C. <joh...@gm...>]

I added a .hgignore file to the top of the mercurial repo. I've added
everything we'd normally not want to see when running "hg status".

 

John

Re: [Openslp-devel] [PATCH] simplify interface list parsing

[John C. <joh...@gm...>]

David,

Thanks for the patches. In case you haven't been following for the last
couple of weeks, we switched to a mercurial repository. The three patches
you submitted have been applied to tip of default and should be in the 2.0
release when it goes out in a week or so here.

Regards,
John

> -----Original Message-----
> From: David L Stevens [mailto:dls...@us...]
> Sent: Tuesday, November 27, 2012 10:07 AM
> To: ope...@li...
> Subject: [Openslp-devel] [PATCH] simplify interface list parsing
> 
> 
> This patch replaces by-hand pointer tracking while parsing comma-separated
> IP addresses with a simple loop using the POSIX standard strtok_r()
function.
> 
> Signed-Off-By: David L Stevens <dls...@us...>
> 
> diff --git a/common/slp_iface.c b/common/slp_iface.c index
> b512986..e1423a3 100644
> --- a/common/slp_iface.c
> +++ b/common/slp_iface.c
> @@ -737,29 +737,24 @@ int SLPIfaceGetInfo(const char * useifaces,
> SLPIfaceInfo * ifaceinfo,
> 
>        if (p)
>        {
> -         char * ep = p + strlen(p);
> -         char * slider1 = p;
> -         char * slider2 = p;
> +         char *token, *saveptr;
>           char interface[MAX_IFACE_LEN];
>           int ret = 0;
> 
> -         while (slider1 < ep)
> +         for (token = strtok_r(p, ",", &saveptr); token;
> +            token = strtok_r(NULL, ",", &saveptr))
>           {
> -            while (*slider2 != 0 && *slider2 != ',')
> -               slider2++;
> -            *slider2 = 0;
> -
> -            ret = SLPD_Get_Iface_From_Ip(slider1, (char *)&interface);
> +            ret = SLPD_Get_Iface_From_Ip(token, (char *)&interface);
> 
>              if (SLPIfaceContainsAddr(useifaceslen, useifaces,
> -                  strlen(slider1), slider1))
> +                  strlen(token), token))
>              {
>                 sockfd_t fd;
>                 struct sockaddr_in v4addr;
>                 struct sockaddr_in6 v6addr;
> 
>                 /* check if an ipv4 address was given */
> -               if (SLP_inet_pton(AF_INET, slider1, &v4addr.sin_addr) ==
1)
> +               if (SLP_inet_pton(AF_INET, token, &v4addr.sin_addr) ==
> + 1)
>                 {
>                    if (SLPNetIsIPV4() && ((family == AF_INET) || (family
==
> AF_UNSPEC)))
>                    {
> @@ -776,7 +771,7 @@ int SLPIfaceGetInfo(const char * useifaces,
> SLPIfaceInfo * ifaceinfo,
>                       }
>                    }
>                 }
> -               else if (SLP_inet_pton(AF_INET6, slider1,
&v6addr.sin6_addr) == 1)
> +               else if (SLP_inet_pton(AF_INET6, token,
> + &v6addr.sin6_addr) == 1)
>                 {
>                    if (SLPNetIsIPV6() && ((family == AF_INET6) || (family
==
> AF_UNSPEC)))
>                    {
> @@ -798,7 +793,6 @@ int SLPIfaceGetInfo(const char * useifaces,
> SLPIfaceInfo * ifaceinfo,
>                 else
>                    sts = (errno = EINVAL), -1;   /* not v4, not v6 */
>              }
> -            slider1 = ++slider2;
>           }
>        }
>        xfree(p);
> 
> 
>
----------------------------------------------------------------------------
--
> Monitor your physical, virtual and cloud infrastructure from a single web
> console. Get in-depth insight into apps, servers, databases, vmware, SAP,
> cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel

[Openslp-devel] mercurial instructions

[John C. <joh...@gm...>]

Ok - now that we've moved over to mercurial, perhaps a little introduction
and a few ground rules would be in order:

 

First, mercurial (as you know) is a distributed version control system
(DVCS), which basically means one thing - your work area is a snapshot of
the entire repository, including all history, branches, tags, etc. Under a
traditional non-distributed VCS system like CVS or Subversion, this would be
expensive, but a DVCS manages your work area history as a set of diffs from
one revision to the next, so it's pretty efficient. If you still have your
subversion work area around, you might do a size comparison just for the fun
of it.

 

Like subversion, mercurial manages its historical information in a "hidden"
sub-directory called .hg. Unlike subversion, there's only one of these .hg
directories right under the root of the repo. Many of the features of
subversion have corollary functionality in mercurial, such as the "update"
command, the "status" command, etc. These functions operate just as you'd
expect them to. Some mercurial functionality, however is different and you
need to understand these differences to use them properly. 

 

For instance, the commit operation exists in mercurial, but it  commits a
change set to your local copy of the repository. In fact, the update command
updates from your local copy of the repository, rather than from the copy on
sourceforge.net. This is very nice because you have the opportunity to
modify your local history until it's just the way you like it. When you're
ready to publish your changes to the world, you use the "push" command to
push your local changes up to the master repo. Be careful with push - once
you push, you're committed in the same manner you were under subversion
commit. Until you push, however, everything in your copy of the repo is fair
game for changes you might like to make to it.

 

In reality, there is no concept of a "master" repo in a DVCS. Technically,
everyone's copy of a repository is just as valid as anyone else's copy.
However, to maintain some semblance of sanity in a project, a particular
copy of the repo is usually designated (by general agreement) as the
"master" copy. In this case, the master copy is the one hosted by
sourceforge.net.

 

When you "clone" a repository, the default push/pull path for your
repository is automatically configured to be the location from which you
cloned. This makes it simple to push your changes back to the same repo from
which you originally cloned - you simply "hg push" and your changes go back
to the repo your data originally came from. This origination information is
stored in a configuration file within the repo's .hg directory - it's called
.hg/hgrc. Cat or Type this file after you clone your repo and you'll see it
contains two lines: 

 

[paths]

default = ssh://jca...@hg.../p/openslp/mercurial

 

You can change the default path for push/pull by simply changing this line
of text in the .hg/hgrc file, or you can use a location URL argument to the
push/pull commands to override the default path. Having the default path
configured in this way makes it easier to work in a manner that's similar
(if not the same as) the way we worked under subversion, updating from, and
pushing changes to a "master" repo.

 

There's a master configuration file found in the root of your user directory
called ~/.hgrc. You can add configuration lines to this file to provide
enhanced functionality tailored for your work habits or needs.

 

Here's a copy of my ~/.hgrc file (slightly edited to remove project-specific
entries) for your information:

 

# --- User interface --- #

[ui]

username  =  John Calcote <joh...@gm...> 

ssh = "c:\program files (x86)\putty\plink.exe" -ssh -l jcalcote -i
"c:\users\jcalcote\keys\id_rsa.ppk" -batch

 

[trusted]

users = *

groups = *

 

[extensions]

hgsubversion = /users/jcalcote/dev/hg/hgsubversion/hgsubversion

color =

transplant =

purge =

graphlog =

rebase =

mq =

fetch =

graphlog =

progress =

 

[color]

mode = auto

status.modified = magenta bold

status.added = green bold

status.removed = red bold

status.deleted = cyan bold

status.unknown = blue bold

status.ignored = black bold

 

[extdiff]

cmd.meld = meld

 

[merge-tools]

meld.args = $base $local $other

 

[tortoisehg]

vdiff = meld

ui.language = en

editor = "C:\Program Files (x86)\notepad++\notepad++.exe"

tabwidth = 3

forcerepotab = True

 

Another difference that's important to recognize is that while you're making
changes to your copy of the repo, another team member is making changes to
his copy also. Conflicts occur when you both try to push your modified repos
to the "master". When this happens, the second push causes a branch to be
created in the master repo that must be merged back into the main line. It's
the second guy's job to merge. 

 

In my professional use of mercurial, we use a "gatekeeper" to ensure that
branches aren't created in the master repo. Changes are bundled up and
pushed to the gatekeeper's mail box. He unbundles these changes, and commits
them when he's satisfied they meet all the criteria for a valid commit. We
don't have a gatekeeper in our setup, so we have to be more careful in how
we work if we want to keep a decent looking master repo. One way to do this
is to use a patch queue. In the above .hgrc file, you'll see an entry under
the [extensions] section, "mq=". This entry enables mercurial patch queues,
which is built into later versions of mercurial, but must be enabled with
this configuration statement. Once enabled, you can treat your changes like
a stack of patches that can be pushed onto and popped off of your local
history - a set of semi-committed changes that can be manipulated more
readily with a patch queue than without.

 

hg qnew -m "Some commit message" patch-name.patch

hg qpush

hg qpop

hg qseries (displays the current patch stack)

 

With patches enabled, you can pull the latest code from sf.net and make
changes to it over several days or weeks, keeping your changes in a set of
patches. When you're ready to push your changes to the master repo, you pop
all your patches, pull the latest code down from sf.net and then push your
patches back on. This effectively moves the conflicts down to your local
repo. You can fix any conflicts that might have been created by changes
pushed up to sf.net while you were working. You can also incrementally
update your local repo on a daily basis under your patch queue in order to
reduce the amount of conflict you have to deal with all at once just before
you're ready to push. 

 

When a conflict does happen because you and another were unlucky enough to
push at the same time (usually within the same 5 minute period), then the
last one in will have to merge in the master. This means pulling down an
updated copy after the conflict has been created, and merging the branches
together, then pushing back up again. I'm making it a rule that the second
pusher (the one whose changes didn't make it into the master on the tip of
the branch) be the person responsible for the merge in order to keep the
conflict from happening multiple times in a row because to pusher's keep
trying to do the merge at the same time. All of this is unlikely in our
project, but it's worth having a plan for when/if it does.

 

I highly recommend reading (or at least skimming) the mercurial manual,
published by the authors of mercurial - Selenic Consulting:

 

http://mercurial.selenic.com/

 

It's fairly light reading and very helpful. I also highly recommend the use
of a graphical tool to manage certain aspects of your repo. TortoiseHG is a
wonderful addition to your tool box - it's written in QT and is thus
portable to both Windows and Linux. You can install it on linux from apt-get
or zypper or whatever platform software installation tool. You can install
it on windows by downloading an installer - google it. When you run "thg"
from the command line in a working directory, TortoiseHG presents a
graphical display of your local repo, including your patch queue and any
local commits you may have made. It really helps you get your head around
your repo's recent history and the way patches are applied to that history.

 

Regards,

John

[Openslp-devel] [PATCH] simplify interface list parsing

[David L S. <dls...@us...>]

This patch replaces by-hand pointer tracking while parsing comma-separated
IP addresses with a simple loop using the POSIX standard strtok_r() function.

Signed-Off-By: David L Stevens <dls...@us...>

diff --git a/common/slp_iface.c b/common/slp_iface.c
index b512986..e1423a3 100644
--- a/common/slp_iface.c
+++ b/common/slp_iface.c
@@ -737,29 +737,24 @@ int SLPIfaceGetInfo(const char * useifaces, SLPIfaceInfo * ifaceinfo,
 
       if (p)
       {
-         char * ep = p + strlen(p);
-         char * slider1 = p;
-         char * slider2 = p;
+         char *token, *saveptr;
          char interface[MAX_IFACE_LEN];
          int ret = 0;
 
-         while (slider1 < ep)
+         for (token = strtok_r(p, ",", &saveptr); token;
+            token = strtok_r(NULL, ",", &saveptr))
          {
-            while (*slider2 != 0 && *slider2 != ',') 
-               slider2++;
-            *slider2 = 0;
-
-            ret = SLPD_Get_Iface_From_Ip(slider1, (char *)&interface);
+            ret = SLPD_Get_Iface_From_Ip(token, (char *)&interface);
 
             if (SLPIfaceContainsAddr(useifaceslen, useifaces, 
-                  strlen(slider1), slider1))
+                  strlen(token), token))
             {
                sockfd_t fd;
                struct sockaddr_in v4addr;
                struct sockaddr_in6 v6addr;
 
                /* check if an ipv4 address was given */
-               if (SLP_inet_pton(AF_INET, slider1, &v4addr.sin_addr) == 1)
+               if (SLP_inet_pton(AF_INET, token, &v4addr.sin_addr) == 1)
                {
                   if (SLPNetIsIPV4() && ((family == AF_INET) || (family == AF_UNSPEC)))
                   {
@@ -776,7 +771,7 @@ int SLPIfaceGetInfo(const char * useifaces, SLPIfaceInfo * ifaceinfo,
                      }
                   }
                }
-               else if (SLP_inet_pton(AF_INET6, slider1, &v6addr.sin6_addr) == 1)
+               else if (SLP_inet_pton(AF_INET6, token, &v6addr.sin6_addr) == 1)
                {
                   if (SLPNetIsIPV6() && ((family == AF_INET6) || (family == AF_UNSPEC)))
                   {
@@ -798,7 +793,6 @@ int SLPIfaceGetInfo(const char * useifaces, SLPIfaceInfo * ifaceinfo,
                else
                   sts = (errno = EINVAL), -1;   /* not v4, not v6 */
             }
-            slider1 = ++slider2;
          }
       }
       xfree(p);

[Openslp-devel] [PATCH] allow interface names in the interface list

[David L S. <dls...@us...>]

This patch allows interface names in addition to IPv4 and IPv6 addresses in
the slp_interfaces list. Interfaces still have to have a valid address to be
used, but the address doesn't have to be known when writing the config file.

Signed-Off-By: David L Stevens <dls...@us...>

diff --git a/common/slp_iface.c b/common/slp_iface.c
index e1423a3..8eb471b 100644
--- a/common/slp_iface.c
+++ b/common/slp_iface.c
@@ -690,6 +690,50 @@ static int SLPD_Get_Iface_From_Ip(char *ip, char *iface) {
    return 0;
 }
 
+/** Get an IP address for an interface
+ *
+ * Fills in sockaddr with a valid address on the given interface and returns
+ * the length of the socket address
+ *
+ * @param[in] ifaddrs0 - pointer to ifaddrlist, or NULL
+ * @param[in] ifname - Pointer to interface name
+ * @param[in] family - A hint indicating the address family to get info 
+ *    for - can be AF_INET, AF_INET6, or AF_UNSPEC for both.
+ * @param[out] sa - sockaddr containing an address on interface "ifname"
+ *
+ * @return Zero on failure, sizeof(sockaddr_in) for AF_INET,
+ *     sizeof(sockaddr_in6) for AF_INET6
+ */
+static int ifname_to_addr(struct ifaddrs *ifaddrs0, char *ifname, int family,
+                          struct sockaddr *sa)
+{
+   int salen = 0;
+   struct ifaddrs *ifaddrs, *ifa;
+
+   ifaddrs = ifaddrs0;
+
+   if (ifaddrs == NULL && getifaddrs(&ifaddrs) < 0)
+      return 0;
+   for (ifa = ifaddrs; ifa; ifa = ifa->ifa_next)
+   {
+      if (strcmp(ifa->ifa_name, ifname) != 0)
+         continue;
+      if (family != AF_UNSPEC && ifa->ifa_addr->sa_family != family)
+         continue;
+      switch (ifa->ifa_addr->sa_family) {
+      case AF_INET: salen = sizeof(struct sockaddr_in); break;
+      case AF_INET6: salen = sizeof(struct sockaddr_in6); break;
+      default:
+         continue;
+      }
+      memcpy(sa, ifa->ifa_addr, salen);
+      break;
+   }
+   if (!ifaddrs0)
+      freeifaddrs(ifaddrs);
+   return salen;
+}
+
 /** Get the network interface addresses for this host.
  * 
  * Returns either a complete list or a subset of the list of network interface 
@@ -739,8 +783,12 @@ int SLPIfaceGetInfo(const char * useifaces, SLPIfaceInfo * ifaceinfo,
       {
          char *token, *saveptr;
          char interface[MAX_IFACE_LEN];
+         struct ifaddrs *ifaddrs;
          int ret = 0;
 
+         if (getifaddrs(&ifaddrs) < 0)
+            ifaddrs = NULL;
+
          for (token = strtok_r(p, ",", &saveptr); token;
             token = strtok_r(NULL, ",", &saveptr))
          {
@@ -793,7 +841,20 @@ int SLPIfaceGetInfo(const char * useifaces, SLPIfaceInfo * ifaceinfo,
                else
                   sts = (errno = EINVAL), -1;   /* not v4, not v6 */
             }
+            else if (if_nametoindex(token))
+            {
+               struct sockaddr_storage ss;
+               int salen;
+
+               salen = ifname_to_addr(ifaddrs, token, family,
+                                      (struct sockaddr *)&ss);
+               if (salen > 0)
+                  memcpy(&ifaceinfo->iface_addr[ifaceinfo->iface_count++],
+                         &ss, salen);
+            }
          }
+         if (ifaddrs)
+            freeifaddrs(ifaddrs);
       }
       xfree(p);
    }

[Openslp-devel] [PATCH] simplify/speed-up SLPD_Get_Iface_From_Ip()

[David L S. <dls...@us...>]

This patch simplifies SLPD_Get_Iface_From_Ip(). Instead of repeatedly calling
strlen(), it uses strchr() to get interface names from IP address
specifications.

Signed-Off-By: David L Stevens <dls...@us...>

diff --git a/common/slp_iface.c b/common/slp_iface.c
index 8876873..b512986 100644
--- a/common/slp_iface.c
+++ b/common/slp_iface.c
@@ -675,30 +675,19 @@ int SLPIfaceGetDefaultInfo(SLPIfaceInfo* ifaceinfo, int family)
  */ 
 static int SLPD_Get_Iface_From_Ip(char *ip, char *iface) {
 
-    char *ip_ptr = ip;
-   unsigned int i = 0;
-   int ret = -1;
-
-    if(iface == NULL)
-             return ret;
-
-    while(i != strlen(ip)) {
-             if(*ip_ptr != '%') {
-                      ip_ptr++;
-                      i++;
-                      continue;
-             } else {
-                      ip_ptr++;
-                      if (strlen(ip_ptr) >= MAX_IFACE_LEN) {
-                             break;
-                      } else {
-                             strcpy(iface, ip_ptr);
-                             ret = 0;
-                             break;
-                      }
-            }
-    }
-    return ret;
+   char *p;
+
+   if (iface == NULL)
+      return -1;
+
+   p = strchr(ip, '%');
+   if (p == NULL)
+      return -1;
+   ++p;
+   if (strlen(p) >= MAX_IFACE_LEN)
+      return -1;
+   (void) strcpy(iface, p);
+   return 0;
 }
 
 /** Get the network interface addresses for this host.

[Openslp-devel] Mercurial repository created

[John C. <joh...@gm...>]

No one complained for a week, and all votes seemed to be in reasonable favor
of Mercurial so Mercurial it is.

 

I've created the Mercurial repository and imported the subversion repo
history into it from revisions 1 to 1703. 

 

To avoid having people accidentally commit additional code to the subversion
repo, I've disabled all but read-only access to everyone. 

 

You'll find a new Mercurial link at the top of the sourceforge.net project
page. Please use one of the following command lines to check out a mercurial
work area:

 

For ssh access: 

     hg clone ssh://jca...@hg.../p/openslp/mercurial openslp

 

For https access: 

     hg clone https://jca...@hg.../p/openslp/mercurial openslp

 

Https access is purported by SF staff to be a bit slower than ssh, but for
ssh you'll probably need to add a public key to your profile if you haven't
already done so.

 

I know it's customary to use an email address when committing to a DVCS, but
I'd like us to continue to use our sf.net user ids so there's some
continuity between the original repo and new commits.

 

If you've never tried it before, look at TortoiseHG - it's a QT-based qui
tool that really gives you a nice view of the repository. And it can make
some operations on your local work area much easier than the command line.
It's also portable between windows and linux (I have versions of it
installed on both my windows and linux machines).

 

Thanks,

John

Re: [Openslp-devel] SourceForge.net site update in progress...

[HIRD M. <Mat...@uk...>]

sorry, been off all last week.

+1 for mercurial for me.



From: Nick Wagner [mailto:ne...@wi...]
Sent: 14 November 2012 20:20
To: John Calcote
Cc: OpenSLP Devel Mailing List
Subject: Re: [Openslp-devel] SourceForge.net site update in progress...

I used git a little bit, but I haven't really used a DVCS professionally.  +1 for either git or mercurial.

On Wed, Nov 14, 2012 at 12:12 PM, John Calcote <joh...@gm...<mailto:joh...@gm...>> wrote:
OpenSLP developers,

I have two issues to bring up this morning.

OpenSLP Site Update

While out on sf.net<http://sf.net> today, I noticed that there was a site update available to which project admins must "opt in". I carefully read the documentation about the update to ensure that it would have no negative impact on our project or developers, but apparently I missed the part where the repositories are updated to new locations and directory structures. Thus (and I apologize for any inconvenience this may cause) you will need to check out a new work area using the new svn repository locations before committing any more work to the repo. You can find the new repo locations listed on this page:

    https://sourceforge.net/p/openslp/code/

Click the "RW" button to ensure you're using the URL that will grant you read/write access. The new location follows this pattern (where sfuserid is your sourceforge user id):

    ssh://sfu...@sv.../p/openslp/code/trunk<http://sfu...@sv.../p/openslp/code/trunk> openslp-code

Thus, you can use the following command to get your new work area:

    svn checkout --username=sfuserid svn+ssh://sfu...@sv.../p/openslp/code/trunk<http://sfu...@sv.../p/openslp/code/trunk> openslp-code

The repo is currently updating, so please wait till the import has completed before checking out your new work areas. The import status is available at the top of the page on the link above.

Distributed Version Control

Now on to the next topic: I'm considering switching to a distributed version control system (DVCS) like git or mercurial. These tools are nearly identical, so I'm not particularly concerned which one we use, but since I've started using a DVCS professionally a couple of years ago, I've begun to wonder why anyone stays with centralized VCS systems like CVS or Subversion anymore. The mercurial patch queue features alone are worth the switch.

My only concern, at this point, is that some of you may not be familiar or comfortable with DVCS's because your work experience hasn't taken you in that direction yet. So I'll leave it up to you - let's take a vote and see if we're willing and able to switch over to a DVCS, and which one we would prefer. My vote is:

    +1/mercurial

I have to tell you that, while I don't mind using git, there are a couple of reasons I prefer mercurial: 1) I've been using mercurial so I understand it completely, and 2) mercurial is written in python, so it has none of the (Windows) portability issues associated with git (Cygwin/msys, etc).

John


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Openslp-devel mailing list
Ope...@li...<mailto:Ope...@li...>
https://lists.sourceforge.net/lists/listinfo/openslp-devel

[Openslp-devel] AUTO: Sushil H Sharma is out of the office. (returning 11/16/2012)

[Sushil H S. <sus...@in...>]

I am out of the office until 11/16/2012.

In case of any urgent queries, kindly contact swa...@in... or
chh...@in....
I will respond to your message when I return.


Note: This is an automated response to your message  "Openslp-devel Digest,
Vol 48, Issue 9" sent on 14/11/2012 23:42:59.

This is the only notification you will receive while this person is away.

Re: [Openslp-devel] SourceForge.net site update in progress...

[Nick W. <ne...@wi...>]

I used git a little bit, but I haven't really used a DVCS professionally.
 +1 for either git or mercurial.


On Wed, Nov 14, 2012 at 12:12 PM, John Calcote <joh...@gm...>wrote:

> OpenSLP developers,****
>
> ** **
>
> I have two issues to bring up this morning.****
>
> ** **
>
> *OpenSLP Site Update*
>
> ** **
>
> While out on sf.net today, I noticed that there was a site update
> available to which project admins must “opt in”. I carefully read the
> documentation about the update to ensure that it would have no negative
> impact on our project or developers, but apparently I missed the part where
> the repositories are updated to new locations and directory structures.
> Thus (and I apologize for any inconvenience this may cause) you will need
> to check out a new work area using the new svn repository locations before
> committing any more work to the repo. You can find the new repo locations
> listed on this page:****
>
> ** **
>
>     https://sourceforge.net/p/openslp/code/****
>
> ** **
>
> Click the “RW” button to ensure you’re using the URL that will grant you
> read/write access. The new location follows this pattern (where sfuserid is
> your sourceforge user id):****
>
> ** **
>
>     ssh://sfu...@sv.../p/openslp/code/trunk openslp-code****
>
> ** **
>
> Thus, you can use the following command to get your new work area:****
>
> ** **
>
>     svn checkout --username=sfuserid svn+ssh://
> sfu...@sv.../p/openslp/code/trunk openslp-code****
>
> ** **
>
> The repo is currently updating, so please wait till the import has
> completed before checking out your new work areas. The import status is
> available at the top of the page on the link above.****
>
> ** **
>
> *Distributed Version Control*
>
> ** **
>
> Now on to the next topic: I’m considering switching to a distributed
> version control system (DVCS) like git or mercurial. These tools are nearly
> identical, so I’m not particularly concerned which one we use, but since
> I’ve started using a DVCS professionally a couple of years ago, I’ve begun
> to wonder why anyone stays with centralized VCS systems like CVS or
> Subversion anymore. The mercurial patch queue features alone are worth the
> switch. ****
>
> ** **
>
> My only concern, at this point, is that some of you may not be familiar or
> comfortable with DVCS’s because your work experience hasn’t taken you in
> that direction yet. So I’ll leave it up to you – let’s take a vote and see
> if we’re willing and able to switch over to a DVCS, and which one we would
> prefer. My vote is:****
>
> ** **
>
>     +1/mercurial****
>
> ** **
>
> I have to tell you that, while I don’t mind using git, there are a couple
> of reasons I prefer mercurial: 1) I’ve been using mercurial so I understand
> it completely, and 2) mercurial is written in python, so it has none of the
> (Windows) portability issues associated with git (Cygwin/msys, etc).****
>
> ** **
>
> John****
>
> ** **
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>
>

Re: [Openslp-devel] SourceForge.net site update in progress...

[John C. <joh...@gm...>]

One more comment - I mentioned in my instructions below that you should
click on the RW button to get read/write access. The HTTP button will also
give you read/write access to the repo and may present a better access
mechanism for you. In this case, the URLs are formatted as follows:

 

https://svn.code.sf.net/p/openslp/code/trunk openslp-code

 

so you can use this command to check out your work area

 

svn checkout --username=sfuserid
https://svn.code.sf.net/p/openslp/code/trunk openslp-code

 

Using the HTTPS protocol can allow subversion to save your password locally
(in your ~/.subversion config directory). The ssh+svn requires that you
management passwords using a local agent and private key. Either way works,
but the https option may be easier to get going on if you're not an ssh
expert.

 

John

 

From: John Calcote [mailto:joh...@gm...] 
Sent: Wednesday, November 14, 2012 11:30 AM
To: OpenSLP Devel Mailing List
Subject: RE: SourceForge.net site update in progress...

 

The import has completed - you may check out a work area using the new URLs
anytime now. The current status is "Analyzing", but it's okay to check out
while in this state.

 

From: John Calcote [mailto:joh...@gm...] 
Sent: Wednesday, November 14, 2012 11:13 AM
To: OpenSLP Devel Mailing List (ope...@li...)
Subject: SourceForge.net site update in progress...

 

OpenSLP developers,

 

I have two issues to bring up this morning.

 

OpenSLP Site Update

 

While out on sf.net today, I noticed that there was a site update available
to which project admins must "opt in". I carefully read the documentation
about the update to ensure that it would have no negative impact on our
project or developers, but apparently I missed the part where the
repositories are updated to new locations and directory structures. Thus
(and I apologize for any inconvenience this may cause) you will need to
check out a new work area using the new svn repository locations before
committing any more work to the repo. You can find the new repo locations
listed on this page:

 

    https://sourceforge.net/p/openslp/code/

 

Click the "RW" button to ensure you're using the URL that will grant you
read/write access. The new location follows this pattern (where sfuserid is
your sourceforge user id):

 

    ssh://sfu...@sv.../p/openslp/code/trunk openslp-code

 

Thus, you can use the following command to get your new work area:

 

    svn checkout --username=sfuserid
svn+ssh://sfu...@sv.../p/openslp/code/trunk openslp-code

 

The repo is currently updating, so please wait till the import has completed
before checking out your new work areas. The import status is available at
the top of the page on the link above.

 

Distributed Version Control

 

Now on to the next topic: I'm considering switching to a distributed version
control system (DVCS) like git or mercurial. These tools are nearly
identical, so I'm not particularly concerned which one we use, but since
I've started using a DVCS professionally a couple of years ago, I've begun
to wonder why anyone stays with centralized VCS systems like CVS or
Subversion anymore. The mercurial patch queue features alone are worth the
switch. 

 

My only concern, at this point, is that some of you may not be familiar or
comfortable with DVCS's because your work experience hasn't taken you in
that direction yet. So I'll leave it up to you - let's take a vote and see
if we're willing and able to switch over to a DVCS, and which one we would
prefer. My vote is:

 

    +1/mercurial

 

I have to tell you that, while I don't mind using git, there are a couple of
reasons I prefer mercurial: 1) I've been using mercurial so I understand it
completely, and 2) mercurial is written in python, so it has none of the
(Windows) portability issues associated with git (Cygwin/msys, etc).

 

John

 

Re: [Openslp-devel] SourceForge.net site update in progress...

[John C. <joh...@gm...>]

The import has completed - you may check out a work area using the new URLs
anytime now. The current status is "Analyzing", but it's okay to check out
while in this state.

 

From: John Calcote [mailto:joh...@gm...] 
Sent: Wednesday, November 14, 2012 11:13 AM
To: OpenSLP Devel Mailing List (ope...@li...)
Subject: SourceForge.net site update in progress...

 

OpenSLP developers,

 

I have two issues to bring up this morning.

 

OpenSLP Site Update

 

While out on sf.net today, I noticed that there was a site update available
to which project admins must "opt in". I carefully read the documentation
about the update to ensure that it would have no negative impact on our
project or developers, but apparently I missed the part where the
repositories are updated to new locations and directory structures. Thus
(and I apologize for any inconvenience this may cause) you will need to
check out a new work area using the new svn repository locations before
committing any more work to the repo. You can find the new repo locations
listed on this page:

 

    https://sourceforge.net/p/openslp/code/

 

Click the "RW" button to ensure you're using the URL that will grant you
read/write access. The new location follows this pattern (where sfuserid is
your sourceforge user id):

 

    ssh://sfu...@sv.../p/openslp/code/trunk openslp-code

 

Thus, you can use the following command to get your new work area:

 

    svn checkout --username=sfuserid
svn+ssh://sfu...@sv.../p/openslp/code/trunk openslp-code

 

The repo is currently updating, so please wait till the import has completed
before checking out your new work areas. The import status is available at
the top of the page on the link above.

 

Distributed Version Control

 

Now on to the next topic: I'm considering switching to a distributed version
control system (DVCS) like git or mercurial. These tools are nearly
identical, so I'm not particularly concerned which one we use, but since
I've started using a DVCS professionally a couple of years ago, I've begun
to wonder why anyone stays with centralized VCS systems like CVS or
Subversion anymore. The mercurial patch queue features alone are worth the
switch. 

 

My only concern, at this point, is that some of you may not be familiar or
comfortable with DVCS's because your work experience hasn't taken you in
that direction yet. So I'll leave it up to you - let's take a vote and see
if we're willing and able to switch over to a DVCS, and which one we would
prefer. My vote is:

 

    +1/mercurial

 

I have to tell you that, while I don't mind using git, there are a couple of
reasons I prefer mercurial: 1) I've been using mercurial so I understand it
completely, and 2) mercurial is written in python, so it has none of the
(Windows) portability issues associated with git (Cygwin/msys, etc).

 

John

 

Re: [Openslp-devel] Considering adding SuSE extensions to OpenSLP 2.0

[John C. <joh...@gm...>]

Nick, 

 

Given the insight inspired by your single question, I believe this change is
too big to take on right before a release. Additionally, it needs some
additional thought because it adds to the public interface defined by slp.h
- such changes should be voted on, not just accepted without critical
thought. Additionally, it adds a significant amount of new code. This can
destabilize the code base - again, not a good thing right before a release.

 

I think mdns enhancements are a good idea, but the way they work should be
discussed in the community, not just accepted without question just because
a particular linux distro's been using them for a while. I feel certain that
we can find a way to integrate mdns enhancements with both minimal and
well-considered changes to the public interface, and without causing
potential future problems in the way OpenSLP works within the framework of
the SLP standard.

 

I'll limit my changes to just relevant security fixes, and we'll take on the
mdns enhancement a bit more slowly for a future release. For now, I'll keep
my changes in a working patch set. 

 

Thanks,

John

 

From: nwa...@gm... [mailto:nwa...@gm...] On Behalf Of Nick
Wagner
Sent: Wednesday, November 14, 2012 9:45 AM
To: John Calcote
Cc: OpenSLP Devel Mailing List; OpenSLP Users Mailing List
Subject: Re: [Openslp-devel] Considering adding SuSE extensions to OpenSLP
2.0

 

If it can be enabled at runtime or even compile time, I'd be ok with it.
How would attributes fit into it, if at all?

 

--Nick

 

On Tue, Nov 13, 2012 at 11:55 AM, John Calcote <joh...@gm...>
wrote:

I'm currently adding the Suse patches (those that haven't made it in
previously) to the repository in preparation for the 2.0 release. I started
applying the smaller ones first - mostly security review patches - and then
realized it would probably be better to add them in the same order they're
specified in the suse rpm spec file to provide the best context for applying
later patches in the list. (I would normally always apply them in order, but
these patches were written for a different code base - 1.2 - so they have to
be applied manually anyway.)

 

Patch number 3 (in the 23 patch set) is the Suse extension patch. They've
added multicast dns functionality to openSLP.

 

     http://en.wikipedia.org/wiki/Multicast_DNS

 

My first reaction to this (a few years ago) was to reject it, but I'm
rethinking it now - it might be a nice 2.0 feature (and Suse's been using it
for years so it's well tested).

 

Question: Is anyone out there opposed to OpenSLP gathering entries from, and
pushing entries into, the mdns space? I don't want to add this if it's going
to cause significant problems for SLP users. Also consider the possibility
of making it both a compile-in option, and runtime-enabled via config
options.

 

John


----------------------------------------------------------------------------
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Openslp-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openslp-devel

 

[Openslp-devel] SourceForge.net site update in progress...

[John C. <joh...@gm...>]

OpenSLP developers,

 

I have two issues to bring up this morning.

 

OpenSLP Site Update

 

While out on sf.net today, I noticed that there was a site update available
to which project admins must "opt in". I carefully read the documentation
about the update to ensure that it would have no negative impact on our
project or developers, but apparently I missed the part where the
repositories are updated to new locations and directory structures. Thus
(and I apologize for any inconvenience this may cause) you will need to
check out a new work area using the new svn repository locations before
committing any more work to the repo. You can find the new repo locations
listed on this page:

 

    https://sourceforge.net/p/openslp/code/

 

Click the "RW" button to ensure you're using the URL that will grant you
read/write access. The new location follows this pattern (where sfuserid is
your sourceforge user id):

 

    ssh://sfu...@sv.../p/openslp/code/trunk openslp-code

 

Thus, you can use the following command to get your new work area:

 

    svn checkout --username=sfuserid
svn+ssh://sfu...@sv.../p/openslp/code/trunk openslp-code

 

The repo is currently updating, so please wait till the import has completed
before checking out your new work areas. The import status is available at
the top of the page on the link above.

 

Distributed Version Control

 

Now on to the next topic: I'm considering switching to a distributed version
control system (DVCS) like git or mercurial. These tools are nearly
identical, so I'm not particularly concerned which one we use, but since
I've started using a DVCS professionally a couple of years ago, I've begun
to wonder why anyone stays with centralized VCS systems like CVS or
Subversion anymore. The mercurial patch queue features alone are worth the
switch. 

 

My only concern, at this point, is that some of you may not be familiar or
comfortable with DVCS's because your work experience hasn't taken you in
that direction yet. So I'll leave it up to you - let's take a vote and see
if we're willing and able to switch over to a DVCS, and which one we would
prefer. My vote is:

 

    +1/mercurial

 

I have to tell you that, while I don't mind using git, there are a couple of
reasons I prefer mercurial: 1) I've been using mercurial so I understand it
completely, and 2) mercurial is written in python, so it has none of the
(Windows) portability issues associated with git (Cygwin/msys, etc).

 

John

 

Re: [Openslp-devel] Considering adding SuSE extensions to OpenSLP 2.0

[Nick W. <ne...@wi...>]

If it can be enabled at runtime or even compile time, I'd be ok with it.
 How would attributes fit into it, if at all?

--Nick


On Tue, Nov 13, 2012 at 11:55 AM, John Calcote <joh...@gm...>wrote:

> I’m currently adding the Suse patches (those that haven’t made it in
> previously) to the repository in preparation for the 2.0 release. I started
> applying the smaller ones first – mostly security review patches - and then
> realized it would probably be better to add them in the same order they’re
> specified in the suse rpm spec file to provide the best context for
> applying later patches in the list. (I would normally always apply them in
> order, but these patches were written for a different code base – 1.2 – so
> they have to be applied manually anyway.)****
>
> ** **
>
> Patch number 3 (in the 23 patch set) is the Suse extension patch. They’ve
> added multicast dns functionality to openSLP.****
>
> ** **
>
>      http://en.wikipedia.org/wiki/Multicast_DNS****
>
> ** **
>
> My first reaction to this (a few years ago) was to reject it, but I’m
> rethinking it now – it might be a nice 2.0 feature (and Suse’s been using
> it for years so it’s well tested).****
>
> ** **
>
> Question: Is anyone out there opposed to OpenSLP gathering entries from,
> and pushing entries into, the mdns space? I don’t want to add this if it’s
> going to cause significant problems for SLP users. Also consider the
> possibility of making it both a compile-in option, and runtime-enabled via
> config options.****
>
> ** **
>
> John****
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>
>

[Openslp-devel] Considering adding SuSE extensions to OpenSLP 2.0

[John C. <joh...@gm...>]

I'm currently adding the Suse patches (those that haven't made it in
previously) to the repository in preparation for the 2.0 release. I started
applying the smaller ones first - mostly security review patches - and then
realized it would probably be better to add them in the same order they're
specified in the suse rpm spec file to provide the best context for applying
later patches in the list. (I would normally always apply them in order, but
these patches were written for a different code base - 1.2 - so they have to
be applied manually anyway.)

 

Patch number 3 (in the 23 patch set) is the Suse extension patch. They've
added multicast dns functionality to openSLP.

 

     http://en.wikipedia.org/wiki/Multicast_DNS

 

My first reaction to this (a few years ago) was to reject it, but I'm
rethinking it now - it might be a nice 2.0 feature (and Suse's been using it
for years so it's well tested).

 

Question: Is anyone out there opposed to OpenSLP gathering entries from, and
pushing entries into, the mdns space? I don't want to add this if it's going
to cause significant problems for SLP users. Also consider the possibility
of making it both a compile-in option, and runtime-enabled via config
options.

 

John

Re: [Openslp-devel] 2.0 release imminent

[John C. <joh...@gm...>]

Matthew - I will look into them and ensure they're incorporated.

Thanks for your efforts,
John

> -----Original Message-----
> From: Matthew Pendlebury [mailto:Matthew.Pendlebury@thales-
> esecurity.com]
> Sent: Thursday, November 08, 2012 2:48 AM
> To: Roel van de Kraats; John Calcote
> Cc: OpenSLP Devel Mailing List
> Subject: RE: [Openslp-devel] 2.0 release imminent
> 
> Roel/John,
> 
> Those patches originated from me, I'd suggest they are still useful.  We
do
> use those changes here and they clean up the build, improve portability
and
> remove erroneous warnings.  As for testing - we are confident that it
works
> well with itself as an slp platform and we've been using this in house
since
> those patches were submitted (which was now quite a while ago).  What we
> haven't done is performed any significant or formal interoperability
testing
> with other flavours of openslp 2.0 beta to see if we've broken something
at a
> protocol or behavioural level.  Although I'd be surprised if that was the
case.
> Hope that helps.
> 
> Cheers
> 
> --Matt
> 
> > -----Original Message-----
> > From: Roel van de Kraats [mailto:rk...@dd...]
> > Sent: 07 November 2012 20:19
> > To: John Calcote
> > Cc: OpenSLP Devel Mailing List
> > Subject: Re: [Openslp-devel] 2.0 release imminent
> >
> > Hi John,
> >
> > Some time ago I went through the tracker and found a few patches that
> > could be useful:
> >
> >
> http://sourceforge.net/tracker/?func=detail&aid=3026749&group_id=1730&
> > atid
> > =101730
> >
> >
> http://sourceforge.net/tracker/?func=detail&aid=3026744&group_id=1730&
> > atid
> > =101730
> >
> >
> > I don't know if they are still relevant and how well-tested they are.
> > Could you have a look?
> >
> > BR,
> > Roel
> >
> > On 11/06/2012 06:11 PM, John Calcote wrote:
> > >
> > > I'm about to create a 2.0 release of openslp - any issues we need to
> > > cover yet? Speak now or forever hold your peace. :)
> > >
> > > John
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > ----
> > ------
> > > LogMeIn Central: Instant, anywhere, Remote PC access and
> management.
> > > Stay in control, update software, and manage PCs from one command
> > > center Diagnose problems and improve visibility into emerging IT
> > > issues Automate, monitor and manage. Do more in less time with
> > > Central http://p.sf.net/sfu/logmein12331_d2d
> > >
> > >
> > > _______________________________________________
> > > Openslp-devel mailing list
> > > Ope...@li...
> > > https://lists.sourceforge.net/lists/listinfo/openslp-devel
> >
> >
> >
> > ----------------------------------------------------------------------
> > ----
> > ----
> > LogMeIn Central: Instant, anywhere, Remote PC access and management.
> > Stay in control, update software, and manage PCs from one command
> > center Diagnose problems and improve visibility into emerging IT
> > issues Automate, monitor and manage. Do more in less time with Central
> > http://p.sf.net/sfu/logmein12331_d2d
> > _______________________________________________
> > Openslp-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openslp-devel
> 
> Consider the environment before printing this mail.
> 
> Thales e-Security Limited is incorporated in England and Wales with
company
> registration number 2518805. Its registered office is located at 2
Dashwood
> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey
> KT15 2NX.
> 
> The information contained in this e-mail is confidential. It may also be
> privileged. It is intended only for the stated addressee(s) and access to
it by
> any other person is unauthorised. If you are not an addressee or the
> intended addressee, you must not disclose, copy, circulate or in any other
> way use or rely on the information contained in this e-mail. Such
> unauthorised use may be unlawful. If you have received this e-mail in
error,
> please inform us immediately on +44 (0)1223 723600 and delete it and all
> copies from your system.  Commercial matters detailed or referred to in
this
> e-mail are subject to a written contract signed for and on behalf of
Thales e-
> Security Limited.

Re: [Openslp-devel] 2.0 release imminent

[Matthew P. <Mat...@th...>]

Roel/John,

Those patches originated from me, I'd suggest they are still useful.  We do use those changes here and they clean up the build, improve portability and remove erroneous warnings.  As for testing - we are confident that it works well with itself as an slp platform and we've been using this in house since those patches were submitted (which was now quite a while ago).  What we haven't done is performed any significant or formal interoperability testing with other flavours of openslp 2.0 beta to see if we've broken something at a protocol or behavioural level.  Although I'd be surprised if that was the case.  Hope that helps.

Cheers

--Matt

> -----Original Message-----
> From: Roel van de Kraats [mailto:rk...@dd...]
> Sent: 07 November 2012 20:19
> To: John Calcote
> Cc: OpenSLP Devel Mailing List
> Subject: Re: [Openslp-devel] 2.0 release imminent
>
> Hi John,
>
> Some time ago I went through the tracker and found a few patches that
> could be useful:
>
> http://sourceforge.net/tracker/?func=detail&aid=3026749&group_id=1730&atid
> =101730
>
> http://sourceforge.net/tracker/?func=detail&aid=3026744&group_id=1730&atid
> =101730
>
>
> I don't know if they are still relevant and how well-tested they are.
> Could you have a look?
>
> BR,
> Roel
>
> On 11/06/2012 06:11 PM, John Calcote wrote:
> >
> > I'm about to create a 2.0 release of openslp - any issues we need to
> > cover yet? Speak now or forever hold your peace. :)
> >
> > John
> >
> >
> >
> > ------------------------------------------------------------------------
> ------
> > LogMeIn Central: Instant, anywhere, Remote PC access and management.
> > Stay in control, update software, and manage PCs from one command center
> > Diagnose problems and improve visibility into emerging IT issues
> > Automate, monitor and manage. Do more in less time with Central
> > http://p.sf.net/sfu/logmein12331_d2d
> >
> >
> > _______________________________________________
> > Openslp-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openslp-devel
>
>
>
> --------------------------------------------------------------------------
> ----
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel

Consider the environment before printing this mail.

Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX.

The information contained in this e-mail is confidential. It may also be privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)1223 723600 and delete it and all copies from your system.  Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited.

Re: [Openslp-devel] 2.0 release imminent

[Roel v. de K. <rk...@dd...>]

Hi John,

Some time ago I went through the tracker and found a few patches that 
could be useful:

http://sourceforge.net/tracker/?func=detail&aid=3026749&group_id=1730&atid=101730 

http://sourceforge.net/tracker/?func=detail&aid=3026744&group_id=1730&atid=101730 


I don't know if they are still relevant and how well-tested they are. 
Could you have a look?

BR,
Roel

On 11/06/2012 06:11 PM, John Calcote wrote:
>
> I’m about to create a 2.0 release of openslp – any issues we need to 
> cover yet? Speak now or forever hold your peace. :)
>
> John
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
>
>
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel

Re: [Openslp-devel] 2.0 release imminent

[John C. <joh...@gm...>]

Thanks Nick. I got the novell patches from Aaron - there are a couple dozen
of them, so it'll take me a day or two to go through them all.

 

From: nwa...@gm... [mailto:nwa...@gm...] On Behalf Of Nick
Wagner
Sent: Tuesday, November 06, 2012 1:30 PM
To: Me
Cc: John Calcote; OpenSLP Devel Mailing List
Subject: Re: [Openslp-devel] 2.0 release imminent

 

I've made the change for that bug. 1695

 

On Tue, Nov 6, 2012 at 12:57 PM, Me <da...@gm...> wrote:

Thanks John.  Available at
ftp://ftp.novell.com/outgoing/openslp-1.2.0-172.22.1.src.rpm with md5
checksum: 494ed3b4f2453fbf2b47ab48707b1173

This file includes the base openslp 1.2.0 used and then the patch files to
be applied to it.  One of the files in there shows the order of the patch
files to be applied and I think they include relevant bug numbers and
descriptions.  I can get more details from the bugs if you'd like.


I can also e-mail it, but wasn't sure if cluttering the list with files was
appropriate.

AB





On Tue, Nov 6, 2012 at 10:51 AM, John Calcote <joh...@gm...>
wrote:

Aaron,

 

Please send me the patches again if you can find them. I'll look them over
and see which ones are still applicable (haven't been fixed yet, and the
patch location still exists in a form to which the patch can be applied).

 

--john

 

From: Me [mailto:da...@gm...] 
Sent: Tuesday, November 06, 2012 10:38 AM
To: OpenSLP Devel Mailing List
Subject: Re: [Openslp-devel] 2.0 release imminent

 

Once upon a time I posted the DIFFs from Novell for all of the openslp 1.x
changes.  I know 2.x has had a ton of things rewritten, but since Novell had
found/fixed all of those bugs has anybody who understands C been able to
glance through those changes to ensure the problems are not present in the
2.x code?  If the code is needed again I can probably get access to the
patch files and post them for whomever; I just hate to have bugs lingering
when somebody else has already gone through the work of analyzing and fixing
them in a way that may work out in 2.x as well as 1.x.

 

On Tue, Nov 6, 2012 at 10:32 AM, Nick Wagner <ne...@wi...> wrote:

How do people feel about http://sourceforge.net/tracker/?func=detail
<http://sourceforge.net/tracker/?func=detail&aid=1751139&group_id=1730&atid=
101730> &aid=1751139&group_id=1730&atid=101730?  I can take some time to
look at it today before the release.  Unfortunately, I'm not in a location
where I can easily look at the windows service deregister bug.

 

--Nick

 

 

 

On Tue, Nov 6, 2012 at 11:11 AM, John Calcote <joh...@gm...>
wrote:

I'm about to create a 2.0 release of openslp - any issues we need to cover
yet? Speak now or forever hold your peace. :)

 

John

 

----------------------------------------------------------------------------
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Openslp-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openslp-devel

 


----------------------------------------------------------------------------
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Openslp-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openslp-devel

 

 


----------------------------------------------------------------------------
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Openslp-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openslp-devel

 

Re: [Openslp-devel] 2.0 release imminent

[Nick W. <ne...@wi...>]

I've made the change for that bug. 1695


On Tue, Nov 6, 2012 at 12:57 PM, Me <da...@gm...> wrote:

> Thanks John.  Available at
> ftp://ftp.novell.com/outgoing/openslp-1.2.0-172.22.1.src.rpm with md5
> checksum: 494ed3b4f2453fbf2b47ab48707b1173
>
> This file includes the base openslp 1.2.0 used and then the patch files to
> be applied to it.  One of the files in there shows the order of the patch
> files to be applied and I think they include relevant bug numbers and
> descriptions.  I can get more details from the bugs if you'd like.
>
> I can also e-mail it, but wasn't sure if cluttering the list with files
> was appropriate.
>
> AB
>
>
>
> On Tue, Nov 6, 2012 at 10:51 AM, John Calcote <joh...@gm...>wrote:
>
>> Aaron,****
>>
>> ** **
>>
>> Please send me the patches again if you can find them. I’ll look them
>> over and see which ones are still applicable (haven’t been fixed yet, and
>> the patch location still exists in a form to which the patch can be
>> applied).****
>>
>> ** **
>>
>> --john****
>>
>> ** **
>>
>> *From:* Me [mailto:da...@gm...]
>> *Sent:* Tuesday, November 06, 2012 10:38 AM
>> *To:* OpenSLP Devel Mailing List
>> *Subject:* Re: [Openslp-devel] 2.0 release imminent****
>>
>> ** **
>>
>> Once upon a time I posted the DIFFs from Novell for all of the openslp
>> 1.x changes.  I know 2.x has had a ton of things rewritten, but since
>> Novell had found/fixed all of those bugs has anybody who understands C been
>> able to glance through those changes to ensure the problems are not present
>> in the 2.x code?  If the code is needed again I can probably get access to
>> the patch files and post them for whomever; I just hate to have bugs
>> lingering when somebody else has already gone through the work of analyzing
>> and fixing them in a way that may work out in 2.x as well as 1.x.****
>>
>> ** **
>>
>> On Tue, Nov 6, 2012 at 10:32 AM, Nick Wagner <ne...@wi...>
>> wrote:****
>>
>> How do people feel about
>> http://sourceforge.net/tracker/?func=detail&aid=1751139&group_id=1730&atid=101730?
>>  I can take some time to look at it today before the release.
>>  Unfortunately, I'm not in a location where I can easily look at the
>> windows service deregister bug.****
>>
>> ** **
>>
>> --Nick****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> On Tue, Nov 6, 2012 at 11:11 AM, John Calcote <joh...@gm...>
>> wrote:****
>>
>> I’m about to create a 2.0 release of openslp – any issues we need to
>> cover yet? Speak now or forever hold your peace. :)****
>>
>>  ****
>>
>> John****
>>
>> ** **
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Openslp-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openslp-devel****
>>
>> ** **
>>
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Openslp-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openslp-devel****
>>
>> ** **
>>
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>
>