[OT] RE: User Notification
Ok, this thread has nothing to do with Struts, so I will make one more pass at it. After this, I'd suggest doing some prototypes and seeing what works best - trial and error with multiple quick prototypes is better learning than asking others to do the work for you. Now, a database can store more than one row for a user, so I'm not understanding why you would store a list of messages in XML format in the database. If databases are new to you, I'd suggest reading a good book on relational DB theory and application. If there is a business or technical reason why you need XML - great, use it! As for what you are trying to do, I think there have been a number of options presented to you, from using JMS to a database to store the messages in either a transient or persistent manner. None of them are actually related to Struts, as Struts is a presentation layer, nothing more. The task you are trying to do is separate from Struts, other than you possibly writing some common Struts code that will offer the necessary lookup of the messages for a user. Try coding some of the solutions and your own with your associates and see how they turn out. Good Luck! James -Original Message- From: Vernon Wu [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 6:49 PM To: Struts Users Mailing List Subject: Re: RE: User Notification What else would you suggest? The reason I am thinking about use DOM is that messages are stored in a XML format in DB since the number of messages can vary. The XML format data needs to be parsed either SAX or DOM. If DOM parsing is too slow, SAX parsing into a collection object is a way to get around. 9/23/2002 3:03:49 PM, Galbreath, Mark [EMAIL PROTECTED] wrote: I hope he means stored as an XML doc. Parsing DOMs are notoriously slow. -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 5:41 PM Sounds like a simple DB-lookup to me. You aren't going to update the client until they refresh at page at least. You'd just have to include something that polled for new messages in each page you wanted them to receive notification. I'm not familiar with what you mean by stored as a DOM or the implications of that, so maybe this is a bad suggestion ;-) Vernon Wu wrote: I need to implement a message system, sort like email but inside the Java web application only for its users. After one user, A, sends a message to another, B, B shall be notified to retrieve the updated messages if B is on line. I plan to implement messages as stored in a DOM. My question is how the notification shall be implemented. I only use a web container, and considering to add in a JMS server for IM. Any suggestions? Thanks, Vernon -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RE: User Notification
Absolutely use SAXP (java.sun.com) or JDOM (www.jdom.org) to parse the XML in a messaging system! DOM parsing would be a big bottleneck on any high-traffic system. Mark -Original Message- From: Vernon Wu [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 7:49 PM The reason I am thinking about use DOM is that messages are stored in a XML format in DB since the number of messages can vary. The XML format data needs to be parsed either SAX or DOM. If DOM parsing is too slow, SAX parsing into a collection object is a way to get around. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RE: User Notification
Yeah, what he said. (I need a cup of coffee *yawn*). Mark -Original Message- From: Joe Barefoot [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 7:53 PM Sorry to intrude, but this is a red herring argument. If you are storing the XML in the DB as character data, SAX is obviously a faster parsing method. If you are storing it as a serialized DOM object, then there is no parsing to be done, just de-serialization. FYI, JDOM builds a DOM-like model of the XML by using JAXP and whatever SAX driver implementation you give it. The slow-down in DOM comes from object creation, so if you are thinking of using SAX to build an object hierarchy or Collection of objects, don't. That's exactly what JDOM does. For small XML data, the difference between JDOM parsing and straight SAX parsing is negligible, particularly if you are going to use the SAX callbacks to create and store Objects (as appears to be the case). If however, you are going to use the callbacks to fire off messages as the XML is parsed (no object storage), then that's a horse of a different color peace, Joe -Original Message- From: Vernon Wu [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 4:49 PM To: Struts Users Mailing List Subject: Re: RE: User Notification What else would you suggest? The reason I am thinking about use DOM is that messages are stored in a XML format in DB since the number of messages can vary. The XML format data needs to be parsed either SAX or DOM. If DOM parsing is too slow, SAX parsing into a collection object is a way to get around. 9/23/2002 3:03:49 PM, Galbreath, Mark [EMAIL PROTECTED] wrote: I hope he means stored as an XML doc. Parsing DOMs are notoriously slow. -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 5:41 PM Sounds like a simple DB-lookup to me. You aren't going to update the client until they refresh at page at least. You'd just have to include something that polled for new messages in each page you wanted them to receive notification. I'm not familiar with what you mean by stored as a DOM or the implications of that, so maybe this is a bad suggestion ;-) Vernon Wu wrote: I need to implement a message system, sort like email but inside the Java web application only for its users. After one user, A, sends a message to another, B, B shall be notified to retrieve the updated messages if B is on line. I plan to implement messages as stored in a DOM. My question is how the notification shall be implemented. I only use a web container, and considering to add in a JMS server for IM. Any suggestions? Thanks, Vernon -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [OT] RE: User Notification
True, but I'd like to hear more about what people are doing as far as integrating XSLT into a Struts app. Seems like every time I pick up a tech rag, SOAP and XML/XSLT are on the cover. Mark -Original Message- From: James Higginbotham [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 4:40 AM Ok, this thread has nothing to do with Struts, so I will make one more pass at it. After this, I'd suggest doing some prototypes and seeing what works best - trial and error with multiple quick prototypes is better learning than asking others to do the work for you. Now, a database can store more than one row for a user, so I'm not understanding why you would store a list of messages in XML format in the database. If databases are new to you, I'd suggest reading a good book on relational DB theory and application. If there is a business or technical reason why you need XML - great, use it! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: User Notification
I've had to implement mail like systems like this in a variety of places. If I could just make some suggestions: 1) Notification is usually accomplished as a side-effect of how you store your messages. For instance, if each message is stored with a read-flag, then it's a simple query to find all the messages that are unread. Generally speaking, object models around messages look something like: Mailbox Folder Message A Message B Message C Folder Message E Message F So you probably want to be able to ask the Mailbox if there are any unread messages (which then asks the folders which check the messages.) 2) A database is usually a bad place to store messages, unless they are very simple and short. Do you ever want to support attachments? What about quotas? What about cleaning out unread messages? How do you intend to monitor the message system? I would suggest storing messages on the filesystem, and putting up a simple server to access the data. 3) If something is sort of like email, strongly consider whether it actually is email. If you can actually treat it as email, then you can use all the standard techniques for mail, which include: a) notification of mail receipt b) MIME attachments - plus the whole Javax.mail packages for reading MIME-encoded messages c) standard protocols for fetching mail d) standard systems for filtering mail (a la procmail, etc.) e) standard monitoring techniques f) automatic queue-mechanisms in case part of the system is down. For example: We once implemented a mail-like system which started as simply as you've described it. Then we implemented sending an email when you received a message (the email contained a link to read the message). Then we implemented non-web access via POP3 protocol. Then we implemented attachments. In the end, we had a system that had grown into a mail system but was all homegrown and awful. We ended up replacing it with Sendmail and a filesystem storage mechanism (mbox format), and everything became much cleaner. Plus our system administrators could monitor the message system as if it were just a mail system. Of course, your mileage may vary - all you might need is the simple ability to send notes back and forth. But I'd recommend at exploring whether the system will grow up to be a mail system and so should just start as a mail system. HTH -Peter On Mon, 2002-09-23 at 14:11, Vernon Wu wrote: I need to implement a message system, sort like email but inside the Java web application only for its users. After one user, A, sends a message to another, B, B shall be notified to retrieve the updated messages if B is on line. I plan to implement messages as stored in a DOM. My question is how the notification shall be implemented. I only use a web container, and considering to add in a JMS server for IM. Any suggestions? Thanks, Vernon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: User Notification
Sounds like a simple DB-lookup to me. You aren't going to update the client until they refresh at page at least. You'd just have to include something that polled for new messages in each page you wanted them to receive notification. I'm not familiar with what you mean by stored as a DOM or the implications of that, so maybe this is a bad suggestion ;-) Vernon Wu wrote: I need to implement a message system, sort like email but inside the Java web application only for its users. After one user, A, sends a message to another, B, B shall be notified to retrieve the updated messages if B is on line. I plan to implement messages as stored in a DOM. My question is how the notification shall be implemented. I only use a web container, and considering to add in a JMS server for IM. Any suggestions? Thanks, Vernon -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: User Notification
I want to have a better implementaiton over unnecessary DB access. That is the reason I would like to use a notification mechanism. 9/23/2002 2:41:05 PM, Eddie Bush [EMAIL PROTECTED] wrote: Sounds like a simple DB-lookup to me. You aren't going to update the client until they refresh at page at least. You'd just have to include something that polled for new messages in each page you wanted them to receive notification. I'm not familiar with what you mean by stored as a DOM or the implications of that, so maybe this is a bad suggestion ;-) Vernon Wu wrote: I need to implement a message system, sort like email but inside the Java web application only for its users. After one user, A, sends a message to another, B, B shall be notified to retrieve the updated messages if B is on line. I plan to implement messages as stored in a DOM. My question is how the notification shall be implemented. I only use a web container, and considering to add in a JMS server for IM. Any suggestions? Thanks, Vernon -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: User Notification
I hope he means stored as an XML doc. Parsing DOMs are notoriously slow. -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 5:41 PM Sounds like a simple DB-lookup to me. You aren't going to update the client until they refresh at page at least. You'd just have to include something that polled for new messages in each page you wanted them to receive notification. I'm not familiar with what you mean by stored as a DOM or the implications of that, so maybe this is a bad suggestion ;-) Vernon Wu wrote: I need to implement a message system, sort like email but inside the Java web application only for its users. After one user, A, sends a message to another, B, B shall be notified to retrieve the updated messages if B is on line. I plan to implement messages as stored in a DOM. My question is how the notification shall be implemented. I only use a web container, and considering to add in a JMS server for IM. Any suggestions? Thanks, Vernon -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: User Notification
Ok, then you could use JMS to store a message in a topic and check for it on each request to show the user an indicator if a message exists. But, unless you turn off persistence for the topic, you will be using a DB on the backend anyway. And a query against a DB on a field that is indexed (such as the userid) would be very fast. The other option (assuming you are using only 1 server or have sticky sessions in place) is to create a session manager that you store these messages in a list, stored in a hash keyed by user id. It would probably be a singleton within the app server's VM. You would then check this manager on each request and show the indicator/message as appropriate. Just attach a session listener so that when the user's session times out or you kill it forcefully, your session manager will drop any existing messages. Course, this isn't persistent so if the user isn't signed in, they will never get the message (thus, see option 1 and previous posts to this list). James -Original Message- From: Vernon Wu [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 1:44 PM To: Struts Users Mailing List Subject: Re: User Notification I want to have a better implementaiton over unnecessary DB access. That is the reason I would like to use a notification mechanism. 9/23/2002 2:41:05 PM, Eddie Bush [EMAIL PROTECTED] wrote: Sounds like a simple DB-lookup to me. You aren't going to update the client until they refresh at page at least. You'd just have to include something that polled for new messages in each page you wanted them to receive notification. I'm not familiar with what you mean by stored as a DOM or the implications of that, so maybe this is a bad suggestion ;-) Vernon Wu wrote: I need to implement a message system, sort like email but inside the Java web application only for its users. After one user, A, sends a message to another, B, B shall be notified to retrieve the updated messages if B is on line. I plan to implement messages as stored in a DOM. My question is how the notification shall be implemented. I only use a web container, and considering to add in a JMS server for IM. Any suggestions? Thanks, Vernon -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: User Notification
Yeah you could persist it to a DB though and show the message from the DB when they ask to do that... and just rely on your session-manager-thingie for notification. James Higginbotham wrote: Ok, then you could use JMS to store a message in a topic and check for it on each request to show the user an indicator if a message exists. But, unless you turn off persistence for the topic, you will be using a DB on the backend anyway. And a query against a DB on a field that is indexed (such as the userid) would be very fast. The other option (assuming you are using only 1 server or have sticky sessions in place) is to create a session manager that you store these messages in a list, stored in a hash keyed by user id. It would probably be a singleton within the app server's VM. You would then check this manager on each request and show the indicator/message as appropriate. Just attach a session listener so that when the user's session times out or you kill it forcefully, your session manager will drop any existing messages. Course, this isn't persistent so if the user isn't signed in, they will never get the message (thus, see option 1 and previous posts to this list). James -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: User Notification
I don't follow you. Can you explain with more details? 9/23/2002 3:55:04 PM, Eddie Bush [EMAIL PROTECTED] wrote: Yeah you could persist it to a DB though and show the message from the DB when they ask to do that... and just rely on your session-manager-thingie for notification. James Higginbotham wrote: Ok, then you could use JMS to store a message in a topic and check for it on each request to show the user an indicator if a message exists. But, unless you turn off persistence for the topic, you will be using a DB on the backend anyway. And a query against a DB on a field that is indexed (such as the userid) would be very fast. The other option (assuming you are using only 1 server or have sticky sessions in place) is to create a session manager that you store these messages in a list, stored in a hash keyed by user id. It would probably be a singleton within the app server's VM. You would then check this manager on each request and show the indicator/message as appropriate. Just attach a session listener so that when the user's session times out or you kill it forcefully, your session manager will drop any existing messages. Course, this isn't persistent so if the user isn't signed in, they will never get the message (thus, see option 1 and previous posts to this list). James -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RE: User Notification
What else would you suggest? The reason I am thinking about use DOM is that messages are stored in a XML format in DB since the number of messages can vary. The XML format data needs to be parsed either SAX or DOM. If DOM parsing is too slow, SAX parsing into a collection object is a way to get around. 9/23/2002 3:03:49 PM, Galbreath, Mark [EMAIL PROTECTED] wrote: I hope he means stored as an XML doc. Parsing DOMs are notoriously slow. -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 5:41 PM Sounds like a simple DB-lookup to me. You aren't going to update the client until they refresh at page at least. You'd just have to include something that polled for new messages in each page you wanted them to receive notification. I'm not familiar with what you mean by stored as a DOM or the implications of that, so maybe this is a bad suggestion ;-) Vernon Wu wrote: I need to implement a message system, sort like email but inside the Java web application only for its users. After one user, A, sends a message to another, B, B shall be notified to retrieve the updated messages if B is on line. I plan to implement messages as stored in a DOM. My question is how the notification shall be implemented. I only use a web container, and considering to add in a JMS server for IM. Any suggestions? Thanks, Vernon -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RE: User Notification
Sorry to intrude, but this is a red herring argument. If you are storing the XML in the DB as character data, SAX is obviously a faster parsing method. If you are storing it as a serialized DOM object, then there is no parsing to be done, just de-serialization. FYI, JDOM builds a DOM-like model of the XML by using JAXP and whatever SAX driver implementation you give it. The slow-down in DOM comes from object creation, so if you are thinking of using SAX to build an object hierarchy or Collection of objects, don't. That's exactly what JDOM does. For small XML data, the difference between JDOM parsing and straight SAX parsing is negligible, particularly if you are going to use the SAX callbacks to create and store Objects (as appears to be the case). If however, you are going to use the callbacks to fire off messages as the XML is parsed (no object storage), then that's a horse of a different color peace, Joe -Original Message- From: Vernon Wu [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 4:49 PM To: Struts Users Mailing List Subject: Re: RE: User Notification What else would you suggest? The reason I am thinking about use DOM is that messages are stored in a XML format in DB since the number of messages can vary. The XML format data needs to be parsed either SAX or DOM. If DOM parsing is too slow, SAX parsing into a collection object is a way to get around. 9/23/2002 3:03:49 PM, Galbreath, Mark [EMAIL PROTECTED] wrote: I hope he means stored as an XML doc. Parsing DOMs are notoriously slow. -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 5:41 PM Sounds like a simple DB-lookup to me. You aren't going to update the client until they refresh at page at least. You'd just have to include something that polled for new messages in each page you wanted them to receive notification. I'm not familiar with what you mean by stored as a DOM or the implications of that, so maybe this is a bad suggestion ;-) Vernon Wu wrote: I need to implement a message system, sort like email but inside the Java web application only for its users. After one user, A, sends a message to another, B, B shall be notified to retrieve the updated messages if B is on line. I plan to implement messages as stored in a DOM. My question is how the notification shall be implemented. I only use a web container, and considering to add in a JMS server for IM. Any suggestions? Thanks, Vernon -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: User Notification
I was expounding on James' response - saying that you could actually persist the message somewhere on top of what he suggest for the session manager. If you persist the messages, they will be there when the user arrives. You would have to do an initial check for messages when they login, but could rely on the session manager from that point on (for notification). When a user sends a message (this is an estimation - I do not know JMS) you would persist the message (using whatever method you like best) and the queue a message to be sent so the receiver would be notified if they were on. If they're on, great - they get instant (as instant as a refresh that is) notification of the message. If they aren't on, you just do the check when they login. Disclaimer: I know nothing about how JMS works, and don't want to pretend to be authoritative. I was trying to make a logical following to James' response, but, not knowing JMS architechture myself, I could be way off-base. My point is your could probably use JMS for notification and use a DB/XML/whatever for actual persistence. Vernon Wu wrote: I don't follow you. Can you explain with more details? 9/23/2002 3:55:04 PM, Eddie Bush [EMAIL PROTECTED] wrote: Yeah you could persist it to a DB though and show the message from the DB when they ask to do that... and just rely on your session-manager-thingie for notification. James Higginbotham wrote: Ok, then you could use JMS to store a message in a topic and check for it on each request to show the user an indicator if a message exists. But, unless you turn off persistence for the topic, you will be using a DB on the backend anyway. And a query against a DB on a field that is indexed (such as the userid) would be very fast. The other option (assuming you are using only 1 server or have sticky sessions in place) is to create a session manager that you store these messages in a list, stored in a hash keyed by user id. It would probably be a singleton within the app server's VM. You would then check this manager on each request and show the indicator/message as appropriate. Just attach a session listener so that when the user's session times out or you kill it forcefully, your session manager will drop any existing messages. Course, this isn't persistent so if the user isn't signed in, they will never get the message (thus, see option 1 and previous posts to this list). James -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
