> -----Original Message----- > From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2- > us...@listserver.u2ug.org] On Behalf Of doug chanco > Sent: Friday, April 10, 2009 6:14 PM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] universe sockets > > Wow great points ..... see below for my answers > > dougc > > >A full response to your inquiry really depends on the answer to > > >another question, which is "why are you doing this?" > > > We want to explore other connection options that are not tied to > uniobjects so that if we decide to switch from universe to say database > "x" we can do so easier. >
Keep in mind that any protocol you develop would need to be deployed on the migration platform, which means additional development later. If you're OK with that, then consider the differences in the way that sockets are implemented on various flavors. Before you go about making a custom communications module with the intent of portability, consider making the interface non-sockets oriented. Use O/S files, directories, and file locking to control I/O. You can easily tag sockets to the front of the file I/O handler, outside of the MV comm module. If you're on Linux consider using pipes to do IPC, for example, and tie that in with inetd or xinetd. > > > I would also say that (in this economy) money is probably an issue as > well, we have looked at several of the pick option available and while > they work they also cost and its tough to sell management on a new way > of connecting when uniobjects has done a decent job. > > Also we want to see if a socket call would be faster than a similar > uniobjects one. > That depends on your access architecture and your proprietary protocol. It could potentially be faster or slower. You may not have the time, in the future, to make it faster if it's not. 98 times out of 100 a library-hooked access module will be faster than your sockets interface for simple operations. The 2 times out of 100 that your sockets will be faster, will be due to bloating in a core-hooked access module. That bloat is due it being loaded with complex features that could take you a while to code. There are exceptions, though. Believe me, I still love coding stuff from the ground up as much as Tony used to. :) However, there is a large line between saving "money" and costing yourself and your company considerably more money when you have to constantly tweak things to make the interface perform better as demand grows. Also, I doubt that you will be taking every possible request scenario into consideration when you design your protocol. To get it done as quickly as possible, and with as little expense as possible, it will end up being a narrow-minded solution at first. That means you will be redesigning it in 6 to 12 months. If you decide to go-for-the-gold, you may not get it completed quickly enough for management. They'll pull the plug eventually and ask for a commercial solution to finish the project. So, my advice is go small and go fast. If that's not good enough for everyone then don't waste your time developing a portable framework that already exists. > >Sockets are geeky, fun, and challenging, and quite satisfying when > they >work > > >correctly, but for the most part working at that tier is hardly > > >cost-effective given the plethora of software available to do > > >communications at a higher level. > > This is a good point BUT several things: > > 1. are you not limited to what they provide, so if I wanted to > send/receive data differently than what they provide I cannot. > That "differently" aspect is where the time and money is. If you truly don't like the way the solution is implemented, then move on. Making it "fit" is sometimes more costly than building your own from scratch, with guidance from the solutions you've seen and GPL code available online. > 2. price > Price is subjective. If your time is not considered an expense by management then you will never win the price v/s time argument. > 3. speed cost, would not doing a socket be faster than using some high > level communications system? > That really depends. You will be building a high-level communication system! If you develop a protocol to transmit packages of data, which get transposed into some kind of operation, then you are building a service. Services implement frameworks. Frameworks are used for high-level communication. > >Do you want to do sockets for > > >fun or because your business requires communications? Are you > > >trying to build a better mousetrap or trying to save money? > > I'd say experiment with building a better mousetrap and give us the > ability to easier move from universe, should the situation arise (I > personally hope not as I like pick) > I know. I've been there over and over again. Sometimes it makes business sense, but sometimes you're only wasting your time now with fake visions of glory on the other side. If you leave one string hanging in that framework, it will come back and attack you with no mercy. The attack of the dangling strings is not pretty. I've been through it a few times myself. You can *try* to deal with it in a year or two, deal with it now and draw out the development, or buy software from someone that's dealt with already. I've ended up buying a solution for some of those "fix it later" situations. > >You're going to spend a few weeks on this, now or over time. Is > > >your time really worth less than the free tools from IBM, or > > >commercial tools that only cost a couple hundred bucks? > > > This is a great point that should we decide to go this route but I have > already mentioned this and I actually gave an estimate of a few months > not weeks (but then again I am nowhere near as good at this as > apparently you are). BUT I am curious what products are available for a > few hundred bucks? I would certainly be willing to check them out BUT > its hard to sell our budget committee when we have a product that work > (uniobjects) or can write our own (sockets) > Stop looking at the sale price man! Look at your hourly pay too. Consider what I've written, then re-evaluate. Your project won't be 100% bug free at first, so are you ready to support such a framework right now and also in the future. You will also be supporting the apps that run on top of it too, which will probably get a lot of code work over and over again. > >Also, if you decide to change employers (or your clients change > > >vendors), who is going to get stuck maintaining all of the custom > > >code? > > I suppose another developer which is why if we go this route we are > going to have extensive documentation > > >If I were an IT director I would not allow someone to > > >write a custom socket interface internally for production use. > > Another good point but I pride myself on writing well documented, well > written code but certainly something to keep in mind (your points for > buying versus writing a comm. Layer) > I disagree there. There are instances where proprietary technology, that is stable and implemented correctly, is an immense business value. In some cases, it also gives the company an edge over the competition. An example of that is implementing CXML punchout functionality for Ariba network. There were _no_ MV interfaces for that back in 2000. Heck, there was hardly ANY interfacing available. There still aren't any MV connectors for CXML punchout that I'm aware of. That was a huge business value and edge, which unfortunately didn't take-off with our customers. > Thanks for your input I will certainly share this with my management team > > thanks again > > dougc > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ---------------------------------------- Glen Batchelor IT Director All-Spec Industries phone: (910) 332-0424 fax: (910) 763-5664 E-mail: webmas...@all-spec.com Web: http://www.all-spec.com Blog: http://blog.all-spec.com ---------------------------------------- ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
