Forum OpenACS Q&A: Suggest where or how to research OpenACS vs. other Web systems
yet another open source software system?
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
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
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.
The way Linux was started: one guy just started doing things, put it up on the web and with time other interested people joined.
Draw your own conclusions.
As to "technical limitation" - that seems like a limitation of HTML, not OpenACS. If you're doing stuff through web you'll have exactly the same problem.
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.
a "pleasantly plump" client). There are lots of cases where it
would be nice to add a decent GUI front end to specific OpenACS
functionality. One reason that nobody has done that yet is that the
OpenACS philosophy is to keep it simple on the client side, so
that the toolkit can be used (for end users, anyway) by basically
anyone with a web browser. Your situation is more specific,
though, so you could probably require that your users be able to
run client-side Java, for example. You don't have to go all the way
to Filemaker or Access to create your interface; you could simply
create something in, say, Swing, or Tk, or something like that,
and still keep most of the core logic in OpenACS. After all, there
are plenty of whizzy Java-based calculators, and a cash register
is not very far removed from that sort of a thing.
If you go to a thicker client model, and you forego loose coupling, be aware that your deployment and maintenance situation becomes a complete nightmare. Make sure the advantages you gain from such a move are so clear and obvious that you're ready to deal with this nightmare.
non-programmer who's never afraid to shoot his mouth off about
things he doesn't fully understand) that maybe a syndication-like
approach might be worth considering. We have talked on these
boards about using SOAP or XML-RPC to provide OpenACS
functionality as a service. What difference does it make whether
that service is provided to another web site or a client on
somebody's desktop? If I understand Ben correctly, then the
point is basically to think encapsulation. If you can figure out how
to create an API for communication between your client thingie
and OpenACS, and if you can be reasonably comfortable that you
can make changes you might want to make to OpenACS or to
the client without breaking that API, then you should be OK.
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).
Persistent connections are not maintained by the protocol itself but they can be implemented on top of both HTTP and XML-RPC using the idea of a session and passing session id. It's not being done for you but it's not impossible.
Additionally in XML-RPC you can also implement callbacks/notifications (or whatever the name you fancy) i.e. ability for a server to call the client. Of course in reality you do this by adding the functionality of the server (ability to accept XML-RPC requests and respond to them) to the client so instead of pure client<->server you would have client/server<->client/server. You just define XML-RPC payload that defines a callback and provide the server an address to call. You can do it when you control both the server and client code and they can do pretty much everything. Of course it's not really a property of XML-RPC - you could invent your own syntax to achieve the same thing over HTTP protocol (or any other transport protocol for that matter).
In a way I agree with the spirit (I think) of Jerry's short comment: the distinction between client and server gets blurry and in many cases those terms are used as an approximation of what is really going on.
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.
when the open source flash server components come of age I see us
using them even more.
would look like on their face. We probably could have accomplished
the same thing with Java but Flash worked out fine and the plugin
seems much more lightweight and sturdy.
However, "programming" in Flash 4 ActionScript is hell but if you're
creative you can make it work.