Forum OpenACS Q&A: Suggest where or how to research OpenACS vs. other Web systems

I played with OpenACS 3.2 about a year ago, but now I am trying to
design a system that is quite a ways off base from what OpenACS does.

Where would I go to find people like myself who have a similar system
design itch?

I am interested in automating a small isolated sandwich + coffee +
hardware store. I need to find others trying to do a similar project,
so we can divide the job into small parts and share the accomplishments.

On a technical side, for what I want to do, OpenACS has a fabulous
emphasis on no-nonsense email and data. I would use ACS's email
abilities to organize charge accounts and do both purchasing and
special orders.

The technical problem with OpenACS ( leading me to search wider ) is
how do I make a scrolling cash register screen? It feels to me like
this would be very awkward to implement using HTML forms.

Lee, I know that there is at least one person who began working on an OpenACS system for small bakeries and food shops. I don't know if his work is still around, but I'll do a little look see and privately email you what I find.

Another thing to consider it might be quite possible to use a thick client via an ODBC interface such as Filemaker of Access. Another thing to consider is the Mozilla project and it's approach to UI systems. Either way, there may be a creative way for you to solve your problem without having to deal with browser limitations.

In fact, I wouldn't be surprised if it were possible to solve your problem in the browswer as well.

talli

talli

Server is the entity that waits for XML-RPC requests initated by clients and responds to them.

Exactly the same as HTTP server and HTTP client. And yes, XML-RPC has exactly the same limitations as HTTP. XML-RPC is HTTP with different syntax (or rather it's a syntax and semantics for the payload of an HTTP request).

Here's my take: XML-RPC is implemented as a HTTP POST.  So at first glance, it appears client/server oriented, much as most of the HTTP we've come to love is browser/server oriented.

But RPC stands for remote procedure call, and in that sense, it's a technology implemented by something smarter than your average browser.  Not always though, the blog module I just wrote implements an XML-RPC call from *your* ACS to ping weblogs.com by just using a variant of util_httppost.  In this case the XML-RPC was overkill for weblogs.com, as the return value is ignorable.

With a second look through the eyes of AOLserver, which implements both client and server sides of HTTP, one can see that any entity that needs to implement a sophisticated XML-RPC service can implement both XML-RPC client and server.  Think of it as a socket connection which if I recall, is made of a bundle of two pipes, connected in opposite directions.

In the case of the scrolling cash register, XML-RPC is probably not the protocol I would choose, but it could be done.  The cash register user agent could implement both sides of the XML-RPC protocol and use that to communicate back and forth with the cash register server.  And yes, the session would be embedded within the protocol.

My first take on the scrolling cash register would be to use webbish clients and not platform specific clients.  I would probably use HTTP and Javascript.  Depending on the intended target, you could probably get me to use IE 5.0+ specific dynamic html, or if what was being claimed for dynamic html two years ago finally is true, then IE 5 & Mozilla 6 specific dynamic html.  Done that way and there might be a problem in which the cash register server cannot raise events in the cash register user agent until the user agent polls the server (through a GET, POST, or other request).  But I believe that such an approach would make for over the web installs and easy upgrades, and almost equivalent functionality as one could get in a heavy weight client.

However, "programming" in Flash 4 ActionScript is hell but if you're
creative you can make it work.