Sounds fair to me. I am sure you will see the light some day ;-).
Ciao,
Mark
Gianugo Rabellino wrote:
> Mark J. Stang wrote:
>
> > I think the bottom-line is that the embedded version of Xindice is available
> > to build stand-alone applications or other servers. As such, it is
> > valuable
Mark J. Stang wrote:
I think the bottom-line is that the embedded version of Xindice is available
to build stand-alone applications or other servers. As such, it is
valuable
to many members of the Xindice community. I am very disturbed that
you see a future where it doesn't exist. Like it is
Personally, I for one would have no current use for Xindice
were it not for the embedded version. Nor do I have any
current visions of future uses for anything but the embedded version.
I certainly hope this is not evidence of a movement to do away with the
embedded version...
I also support the em
Gianugo Rabellino wrote:
OK, until now you are making a technical point from a convenience
functionality. Which is fair, but IMHO doesn't really pay off from
what we are losing from an architectural and developer POV: we have to
maintain two drivers, keeping them in sync and evolving them at the
Gianugo Rabellino wrote:
> Mark J. Stang wrote:
> > There are several people who are using the embedded driver
> > on this list. I wrote an XML Server. I can send it requests
> > like "select customer from customers where lastname = 'Stang'".
> > It is a stand-alone process. It communicate
Mark J. Stang wrote:
There are several people who are using the embedded driver
on this list. I wrote an XML Server. I can send it requests
like "select customer from customers where lastname = 'Stang'".
It is a stand-alone process. It communicates via JMS.
So, my Clients "publish" requests f
One more thing, the embedded security requirement is to
keep people from walking up to the machine and just
running the application.
Maybe we should define "UserIds" and "Passwords" as
a standard. I think everyone will need these.
ciao,
Mark
Gianugo Rabellino wrote:
> Mark J. Stang wrote:
> >
Heinrich,
With the embedded version of the server, Xindice is no
longer an issue. My issue now is that I have everything
designed to work with JMS. However, I am in the
process of abstracting my Publish/Subscribe Interface to
make it transport independent. At that time, I should be
able to "dr
On Sun, 5 Jan 2003, Mark J. Stang wrote:
[...]
>With the old version of Xindice, I had to have a seperate
>Xindice process running. So, I had a JMS Server, a
>Cybershop Server and Xindice Server all running.
>To make things more interesting, I used JBoss for my
>JMS server, a little overkill :-)
There are several people who are using the embedded driver
on this list. I wrote an XML Server. I can send it requests
like "select customer from customers where lastname = 'Stang'".
It is a stand-alone process. It communicates via JMS.
So, my Clients "publish" requests for data and my server
Mark J. Stang wrote:
How do you see this working in the embedded mode?
I don't see it as an issue. But first I have to confess that I still
have to be convinced that including the embedded driver in the Xindice
core is a Good Thing. I don't use it, and don't plan to, so I'm almost
totally ignora
How do you see this working in the embedded mode?
Mark
Gianugo Rabellino wrote:
> As you might have noticed, I commited some new code in scratchpad. It's
> nothing special, and it's far from being finished, but I felt that it
> was much better to put it in CVS so that interested parties might
>
As you might have noticed, I commited some new code in scratchpad. It's
nothing special, and it's far from being finished, but I felt that it
was much better to put it in CVS so that interested parties might
discuss it and participate in the development.
Just to make things clear, I'm strongly
13 matches
Mail list logo
