Re: MV-database independence & PHP

>> I guess the biggest question I
>> have is, how do you want the library interfaced?
>
> I would like an API usable from within PHP for CRUD services where I
> could specify a data source of any of the MV platforms. Additionally,
> I would like performance to be great with scalability on each platform.
> I'm sure I'm missing some requirements, but you get the idea ;-)
>

Actually, what I was fishing for was an example of how you plan on
sinking your hooks into every flavor of MV. If you are looking for a BASIC
approach, then you will be limited in the technology that you can use across
O/S platforms. I'm still having problems with that, but I've got an idea for
a more compact framework.

>> I could put together a
>> couple of simple HTML or XML based modules through MVWWW and deploy it
>> later
>> this week on QM,U2,D3,etc if you wanted. I doubt that's what you had in
>> mind
>> though.
>
> You have mentioned before that you have cross-platform connectivity --
> can you point me to anything about it?

Well, it's basically LPD on anti-depressants. There are some latency
issues with the current design and implementation I'm using, but I've worked
with it on OpenQM and D3. I've heard of it being put on U2 as well, but I'm
not sure of all of the server configurations. For the most part, MVWWW
consists of a client, spool, spool service, and a logic service. The client
can be anything including a CGI application, command line tool, system
service, or even a rule in a procmail script(if you want to really get
geeky). The client process contacts the spool service over a socket and
passes a packet of information directly. A process can also drop a request
packet file into the request queue, bypassing the spool service. The logic
service polls the request queue, processes the request packets, and then
writes a response packet to the response spool. If a packet file is dropped
manually, then the client must wait for a response on its own and clean
everything up. If the socket service is contacted instead, then the same
socket is monitored for a response. Since file polling is used on the MV
side, there is no issue of flavor incompatability. Unless, of course, your
flavor of MV does not support O/S filesystem access. The spool service is a
standard I/O service that is called by a network superserver like inetd or
winetd.

Pros:
No need for system level interfacing for the MV database. Only a couple of
loop and read statements needed changing to go from D3 to OpenQM.
The framework is flat and wide open, so you can access it from anything.
You can rewrite any section of the spooler framework in any language. I have
provided "command line" C and Perl examples for Linux and Win32.
File polling means that load balancing can be achieved by multiple DBs,
sharing the same remote file queue. Also, automatic process allocation can
be done based on the status of the request queue.
Since the client and the logic service are the only two things that actually
intepret the packets, there is no packet logic needed until you hit an
end-point. The packet itself can be compressed or molded in transit between
the two.

Cons
Latency is problematic due to file polling and number of steps required to
go round-trip.
The framework is flat and wide open - security is partially left to the
client and mostly left to the logic server
Since file polling is used, the processes have to constantly monitor a
directory. That means license usage and resource waste.

>
>> With the vast variety of interfacing options, it's going to be hard
>> to build a "universal remote" for PHP unless you build it through a
>> couple
>> of levels. If you want speed, then multiple levels is not an option.
>
> If all work with asynch with the UI, that might help mitigate some of
> the loss of speed.
>

You still generate a lot of wasted load, if you're nailing the service
with several calls at a time. The more steps involved with getting data from
A to B, the more likely it will be that you have an unavoidable overload
situation. In my descriptions above, the bottleneck will be the timing of
the FIFO in conjunction with the service process time in MV. Since the logic
service reads the request "links" from a directory, only one service can
determine if work is available right now or not. Well.. here's a little more
info than you probably care to know about:

HTTP.SERVICE is a file polling phantom with an @SUB call. That's basically
the core. A FIFO tree is established in the local FHS:

/var/spool/mvwww/
/var/spool/mvwww/requests/
/var/spool/mvwww/responses/

The root FIFO is polled by the service, awaiting notification that a
request is availble.

A request packet is written to the requests FIFO using a unqiue ID
filename. The root FIFO directory then has a tiny file written to it, with
that request ID filename. When the user process is complete, the logic
service writes a packet back to the responses FIFO using the same ID. The
obvious bottleneck with this kind of architecture is the request link FIFO.
Every process you've loaded is polling that one directory with
open/readu/close. If 10 requests pop up instantly and you have 3 processes
running, then there is going to be lag between the time that process A is
done with the FIFO and process B sees an opportunity to check it. Of course,
since all three process are running asynchronously, it's first come - first
serve in chaotic order. This is good from a theoretical load standpoint, but
it's actually bad since 2 of the 3 process will fail in their "check" cycle
hundreds or thousands of times before the current process has a chance to
release the FIFO. All the while, a client sits and waits for a response.

Sockets are an easy way out, but the code isn't cross-flavor compatible
at all. I'll get into that later, if the interest arises.

>> My
>> first choice with direct integration would be to build a monolithic C
>> module
>> that has a separate driver service. The drivers would have to either be
>> IPC
>> connected daemons/services or shared libs/dll. My choice there would be
>> IPC
>> since it would be easy to load more than one driver service and access
>> them
>> all, randomly, from the same client. An added, and quite important,
>> benefit
>> is the load splitting that will occur among the interface module and the
>> services. A shared object will be loaded and run in the same user heap as
>> the module, while a driver service can be run in its own user space and
>> potentially on its own processor. I'll stop rambling senselessly now.
>
> Some of it made sense to me. I have worked with UOJ, which needed
> connection pooling to scale (which they have with the latest release
> for a price). I have also worked with ODBC. But I have not written
> any such driver and I have not worked on being cross-platform before,
> so you know a lot more than I do about this. Thanks. --dawn
>

I think that it would be worthwhile to look at a simplistic
proof-of-concept project before venturing into something as indepth as a
dynamic driver system. MVWWW was written to be that - a proof-of-concept
project. Some people have actually implemented it as a live service, and I
have to tip my hat to them for being so brave. :P I haven't had time to
start on the second version(proof-of-architecture to me) of MVWWW, so I
don't have anything better to show right now. Give me a few days.

Glen



--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
.

Relevant Pages