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.
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.
>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.
2. price
3. speed cost, would not doing a socket be faster than using some high
level communications system?
>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)
>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)
>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)
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/
