Why on earth do you think it makes any sense to
deliver Word docs. using the Real Time Protocol?
If you describe the overall abililty this is supposed
to provide to the end-user, and the reasons you
thought RTP would be a good way to deliver that,
perhaps we can suggest some more appropriate
ways to communicate the documents, and give
you tips about better forums for help with implementing
those strategies.
Note that I can think of at least 4 ways to get
documents (or any type of 'static' file) to clients,
and 1 or two that are suitable for when those
documents are being created 'on the fly', and
all of which are better than attempting to
force word docs. (hack, choke) through RTP.
hi firstli thanks for ur kind advice.
I'm working on a project and told by my professor to develop a tool to transmit OBJ file through RTP of JMF from a server to a client.
I came across another forum thread that is similar to my problem - http://forum.java.sun.com/thread.jspa?forumID=28&threadID=241327
I may not be clear in describing my problem. So, may be u can refer to the link above and get a better picture of what I'm trying to say.
Thanks for ur help.
> I'm working on a project and told by my professor to
> develop a tool to transmit OBJ file through RTP of
> JMF from a server to a client.
What does your professor say when you ask..
'Why RTP?'
For example, you could write a client/server
set-up where the user connects to the server
via a socket. The client(s) get a list of 'current
documents' to start with, and the server informs
them if new documents appear, or current ones
disappear.
The user then might be able to select any
document in the list to have it downloaded
or displayed, or the lcient software might
'take the initiative and automatically save
the document to local disk.
Now, can you explain to me, what 'delivering
word Docs using RTP' could do, that could
not achieved by the strategy using sockets?
> I came across another forum thread that is similar to
> my problem -
> http://forum.java.sun.com/thread.jspa?forumID=28&threadID=241327
Yes I noticed and read that thread.
- It is from 4 years ago.
- There is a suggestion of a strategy (mostly
suitable for formats such as audio and video)
but no resolution.
- The OP (original poster) is not clear on what
media types they are interested in.
If that thread is a good indicationof how difficult
it is to adapt the RTP protocol to other media
types, I'd say it is a lost cause.
> What does your professor say when you ask..
> 'Why RTP?'
Another thing you might stress to the prof. is
that there are a number of ways to achieve most
conceivable things, using core J2SE.
The JMF on the other hand, is an extra download
for the client. Further, it has not been developed
for some time. The JMF is effectively abandoned.
Ultimately, I think it would be possible to develop
at least 2 different ways to get the Word docs. to
the clients using J2SE, in the time it takes to
determine that it is either too difficult, or impossible,
to achieve using JMF/RTP.
(And if you can convince the prof. to allow core
J2SE and a more sensible strategy, you're in luck,
because the forums that help with J2SE have a
lot more people to help)
Hi
my professor want the tool to work in the push mode. The data transfer is initiates by the source serving the data. The server is responsible for controlling the flow of data.
For my project, I'm suppose to transmit OBJ file from the server side to the client side. Then, at the client side, rendering of the OBJ file in Java 3D will be done.
The choice of JMF on this project is partly due to the fact that it is an continuation of previous project done on JMF.
Can you guide me on the number of ways to do this server and client setup? And, I shall go research on them.
Thanks a million for ur kind help.
...
> my professor want the tool to work in the push mode.
> The data transfer is initiates by the source serving
> the data. The server is responsible for controlling
> the flow of data.
>
> For my project, I'm suppose to transmit OBJ file from
> the server side to the client side. Then, at the
> client side, rendering of the OBJ file in Java 3D
> will be done.
>
> The choice of JMF on this project is partly due to
> the fact that it is an continuation of previous
> project done on JMF.
OK.. From what you've explained above, it seems
I can now tell you..
- Your Prof. knows a lot more about the problem
and the protocol, than I had first realised.
- You Prof. knows a great deal about it more than I do.
- I was wrong in almost everything I was saying.
Sorry.
> Can you guide me on the number of ways to do this
> server and client setup?
Not really in JMF, using RTP, though if you
show some code with a specific problem
(like a stacktrace) I might be able to help
with debugging (this is an interesting problem).
BTW - can you give a little more detail on the original
project using JMF? It seems the source for that will
be invaluable for your current project.
>BTW - can you give a little more detail on the original
>project using JMF? It seems the source for that will
>be invaluable for your current project.
The original project is on transmit audio or video using RTP from server to client side. And, playing the audio and video using the JMF player. I'm suppose to add an additional feature to it which is what i stated before.
At least, you boost my confidence in this project. Thanks.
Hope to hear more advice from this forum.