Home
The Toolkit for Online Communities
17131 Community Members, 0 members online, 1945 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : Suggest where or how to research OpenACS vs. other Web systems

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

Icon of envelope Request notifications

Could you suggest where to look for other people that want to build
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
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.

The way OpenACS was started: one guy just started doing things, put it up on the web and with time other people who found it and were interested - joined.

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.

Yon, from what I remember, the "one guy" who started aD was building the ACS for his PhD and eventually got $38 million from VCs. So I think it might be a little more complicated than how you proposed it.

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

Another approach might be a "not-so-thick" client (also known as
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.
That's a very good point, Michael. A VB client should also be a snap...

talli

Collapse
Posted by Ben Adida on
Before you jump on the thick or plump client bandwagon, consider your deployment issues, specifically redeployment. What happens when you want to update functionality? Believe it or not, Microsoft is the company that describes this best. "Loose coupling" is what you need. Meaning you couple your client and server loosely enough that you can upgrade the server without having to upgrade the client. The web is a very good example of a loosely-coupled environment, and the very concept of loose coupling is what made the web so successful.

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.

On the topic of loose coupling, it strikes me (the
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.
None.
My understanding was that XML-RPC had the same limitation as HTTP in that only the client can initiate a request, and persistent connections are not maintained.  Am I wrong?
What's a client?
Entity that initiates XML-RPC request.

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).

Time to correct myself.

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.

I apologize for being cryptic.  I think you understand my point of view.

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.

I know I'll get a few laughs by adding this, but you can also achieve some nifty gui's with a .swf front-end. Actionscript is pretty much Javascript in Flash 5 and you can completely separate the logic from the interface. It has been used already on some banking systems. You just need to be as careful as you would with the rest of the application. I will contend that SVG's will play a larger role in web-based interfaces than Java will(I stress interface here). You may commence your laughter.
Actually we're using flash as an interface on one of our systems and
when the open source flash server components come of age I see us
using them even more.
What made you use flash on your site?  I am having a really hard time thinking of instances when flash has improved a site's usability.
We needed to allow a user to see what a particular pair of glasses
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.

"What happens when you want to update functionality?
Just as food for thought, I'd look at using scripted documents using TclKit. This separates the platform specific runtime, and would allow the client to automatically upgrade itself from the server as needed.